Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 5603 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.
  • 0
    Hi, Blue, and welcome to the User BB!

    I'm a visual-tactile learner, so without a diagram, I have problems understanding - don't hesitate to be skeptical of my suggestion.  I would agree with your analysis of the problem.

    Rather than applying a Full NAT "Band-Aid," I suggest that you add the DMZ to the VPN tunnels and adjust internal DNS in A and B to resolve to the private IP(s) in the DMZ.  Refer to Accessing Internal or DMZ Webserver from Internal Network.

    Cheers - Bob
    PS The Band-Aid would be: 'Full NAT : {212.134.10.0/24} -> Any -> {1.2.3.4} : from DMZ (Address) to {192.168.2.x}'
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Hi
    Indeed your solution is valid, but not doable in this instance.
    The simplified explanation which you fully understood misses out various reasons why routing DMZ via VPN isn't possible.  (Would need entire multi-site LAN redesigned and, of course, we want the server DMZ entirely isolated from LAN and tunnels.  There is a lot of history on these sites where a full redesign would fix everything, not least using pubic IPs for private, but not changeable in the timescales)

    The DMZ must be accessible via the internet only regardless.

    I did find this last night - Policy Route - a second WAN Connection: Astaro Security Gateway  - which may do the trick - the astaro is a virtual appliance and so adding another interface should be possible, in which case if the DMZ is on its own "public external" interface it should have its own routing tables?

    Not sure I understand the full NAT band aid comment? The "public range" on site B also need to route up the VPN to the centre LAN - so forcing full NAT to DMZ may conflict?
  • 0
    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 

    That's because the public IP in A is not also inside the tunnel.

    Not sure I understand the full NAT band aid comment? The "public range" on site B also need to route up the VPN to the centre LAN - so forcing full NAT to DMZ may conflict? 

    As I said in the earlier post, routing won't work - the VPN will capture the traffic before your manual routes get a chance to work.  The Full NAT is your only solution other than the changes suggested above.  In order for it to not conflict with the IPsec VPN, you're right that, if 1.2.3.4 is also the endpoint for the VPN, you'll need an earlier rule like: 'No NAT : {212.134.10.0/24} -> IPsec -> {1.2.3.4}'. 

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

    The "full NAT" solution, if I read it right, you are saying:-
    'Full NAT : {212.134.10.0/24} -> Any -> {1.2.3.4} : from DMZ (Address) to {192.168.2.x}' 
    'No NAT : {212.134.10.0/24} -> IPsec -> {1.2.3.4}'

    My lack of experience of the Astaro is making the reading of the format of your possible solution a bit tough - but assume you mean:
    Traffic from: 212.134.10.0/24
    Service: ANY (except with other IPsec rule)
    Going to: 1.2.3.4
    Change destination address to : 192.168.2.x  (private IP address of DMZ server which is accessible via 1.2.3.4)

    Hmmm - I see what you are trying to do now.

    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

    So, if I read it right, this would also include the rule you have suggested?

    And these NATs seem to be for the incoming traffic, not the return path which is the problem - as the return to 212.134.10.0/24 is sent back via the VPN tunnel and not the external DMZ interface.

    I was hoping my link posted in previous post, of adding a different external interface to the DMZ (so it doesn't "use" the main Astaro external interface where the VPN terminates) may mean the return traffic will ignore the VPN return especially as its not configured to use it.  

    Seems a bit silly if you can't prioritise routes on interfaces, VPN, static or otherwise?

    Of course, as you may expect, testing this isn't trivial as it does cause downtime in the real world example [:(]
  • 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
  • 0
    Gotcha, understood.  And thanks for the info and taking time to reply.

    Hmmm.
  • 0 in reply to BlueSnowman
    This is now working perfectly and simply.

    VPN tunnel is created to site 2 for both public and private ranges (which breaks access to 1.2.3.4)

    Adding 1.2.3.4 as a "local network" on the astaro, and getting the remote firewall to tunnel 1.2.3.4 over the VPN, then traffic to 1.2.3.4 from any computer on site B is routed over the tunnel, and somehow the astaro deals with this as if it was a normal request, NATs to correct server etc.

    (In real world, its a bunch of hosts in DMZ, so adding entire network).

    Works perfectly.  No extra NATing required - just saying the public ranges are at the end of the tunnel to site B, and site B sending traffic to those ranges up the tunnel.

    Easy.
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?