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
    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 [:(]
Reply
  • 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 [:(]
Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?