Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 5606 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VPN, DMZ and Routing problem

BlueSnowman
Hello!
I will try and explain the problem, facts simplified, and looking for a hint [[:)]]

"Centre" has 2 protected networks on different interfaces LAN 192.168.1.0/24 & DMZ 192.168.2.0/24.  LAN has no access to DMZ and vice versa.  DMZ has single server accessible via HTTP via NAT with public address 1.2.3.4

The "centre" is the only Astaro appliance

All works well.

Remote site (A) has private network 192.168.3.0/24.  With site to site VPN, Remote site A can see LAN, and can access server in DMZ via public address (via internet and NAT).  

Perfect all works well [[:)]]

Remote site (B) has a private network with PUBLIC addresses with 1-2-1 NAT.  So they are using (for example) 212.134.10.0/24 as actual IPs for their clients.  Their firewall presents each client as its "actual" address publically.  

All work well, until....

Site-to-site VPN established between "centre" and "Remote site B".  In this case, all traffic between "centre LAN" and "Remote site B" is fine.

But accessing the DMZ server fails.

We think its because the packet goes:  siteB client (public 212.134.10.x) over internet to DMZ public (1.2.3.4) NAT'd to internal DMZ server (192.168.2.x) which is fine.  But the return route is seen to go over the VPN tunnel (as Astaro knows 212.134.10.x is down the VPN tunnel) - and hence packets never get back.

How do we overcome this?  Its as if the DMZ area on the Astaro uses the routing table of the entire device and sees the return path down the tunnel - whereas we want the routing of the DMZ to send the packets back to the Internet and not know/care about the tunnel.

Suggestions welcome.


This thread was automatically locked due to age.
Parents
  • 0
    So are you categorically saying the info in my link with the secondary external interface won't solve my issue?

    Correct.

    In fact, the order is important, so you need:
    'No NAT : {212.134.10.0/24} -> IPsec -> {1.2.3.4}'
    'Full NAT : {212.134.10.0/24} -> Any -> {1.2.3.4} : from DMZ (Address) to {192.168.2.x}' 

     Traffic from: 212.134.10.0/24
     Service: ANY (except with other, preceding, IPsec rule)
     Going to: 1.2.3.4
     Change Source address to: DMZ (Address)
     and     change destination address to : 192.168.2.x (private IP address of DMZ server which is accessible via 1.2.3.4)


    But there is a NAT rule:
     From any:
     Service HTTP (all we really need for this example)
     Going To 1.2.3.4
     Change destination to 192.168.2.x

    That's a DNAT, and it doesn't work for you for the reason you cited in your first post.

    You can prioritize manually-created static routes, but you can't make them have priority over the automatic routes created by a VPN definition.  You could do it at the command line, but you would have to recreate the situation after every reboot.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0
    So are you categorically saying the info in my link with the secondary external interface won't solve my issue?

    Correct.

    In fact, the order is important, so you need:
    'No NAT : {212.134.10.0/24} -> IPsec -> {1.2.3.4}'
    'Full NAT : {212.134.10.0/24} -> Any -> {1.2.3.4} : from DMZ (Address) to {192.168.2.x}' 

     Traffic from: 212.134.10.0/24
     Service: ANY (except with other, preceding, IPsec rule)
     Going to: 1.2.3.4
     Change Source address to: DMZ (Address)
     and     change destination address to : 192.168.2.x (private IP address of DMZ server which is accessible via 1.2.3.4)


    But there is a NAT rule:
     From any:
     Service HTTP (all we really need for this example)
     Going To 1.2.3.4
     Change destination to 192.168.2.x

    That's a DNAT, and it doesn't work for you for the reason you cited in your first post.

    You can prioritize manually-created static routes, but you can't make them have priority over the automatic routes created by a VPN definition.  You could do it at the command line, but you would have to recreate the situation after every reboot.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?