Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 39 subscribers
  • Views 2383 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

VRF / NAT routing

Matthew LaComb

I have a need to isolate from a business network and wondered what capabilities the Sophos XG (18.5.3) has.  In that, I've built rules for the following:

Packet from 10.1.1.1 destined to a DMZ 192.168.1.1 address, nat out to business site address which sits at 192.168.50.24 (original 10.1.1.1 src 192.168.1.1 dest, translated 192.168.1.1 src, 192.168.50.24 dest).  This is all working fine; however I don't want the firewall to know on a local level that 192.168.50.24 sits on the network (i.e. I don't want to advertise this network or have it visible on the "LAN" side of the firewall, I want it isolated just to this location/DMZ interface). 

In a router I'd do a policy based route to point the resulting post-NAT packet out the DMZ interface.  Can that be done here?  Or - is there VRF functionality to where I can isolate the DMZ off in it's own area?



This thread was automatically locked due to age.
Parents
  • 0

    Just to be sure: You want to NAT but the firewall does not need the interface, you are NATing to to have connected. You can simply have a route to the destination and do the NAT. 

    Afterwards you can deny every other traffic. It is true, we cannot build virtual domains to separate this, but in the end you can get this running as you want. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    I can deny traffic, but I still have to then wipe that destination address from my interior network.  Here's the scenario:

    Firewall at a remote site.  3 interfaces - one RED tunnel back to corporate (LAN), one LAN interface connected to several users (private VLAN), one DMZ interface connected to 3rd party resources.  Let's say corporate is 10.0.0.0/8, private VLAN is 172.16.0.0/24 and DMZ is 192.168.0.0/24, with routes to 192.168.1.0/24 and 192.168.2.0/24 because they have a layer 3 network.

    What happens is I either have to:

    1.  Create a NAT pool and have the 3rd party do NATting as well, which makes some troubleshooting fun for people not knowledgable about that second NAT.

    2.  Route to their network (192.168.1.0/24 and 192.168.2.0/24)

    #1 is easy and my current path forward.  Path #2 ends up - for the remote users at this site - taking 192.168.1.0/24 and 192.168.2.0/24 out of my ability to use those networks within my internal network at a later date.

    If I had a third option - i.e. the 192.168.1.0/24 and 192.168.2.0/24 networks are in a VRF (or Zone) or routed based on packet egress (i.e. I would always Source NAT out of the DMZ) then I could still use those networks on my internal corporate LAN without overlap.

    Long story short - I'm eliminating overlaps with creativity.  Having the route there along with users connected makes this interesting.  I could stand up a second pair of firewalls just for those users on-site - but that's a bit overkill.

Reply
  • 0 in reply to LuCar Toni

    I can deny traffic, but I still have to then wipe that destination address from my interior network.  Here's the scenario:

    Firewall at a remote site.  3 interfaces - one RED tunnel back to corporate (LAN), one LAN interface connected to several users (private VLAN), one DMZ interface connected to 3rd party resources.  Let's say corporate is 10.0.0.0/8, private VLAN is 172.16.0.0/24 and DMZ is 192.168.0.0/24, with routes to 192.168.1.0/24 and 192.168.2.0/24 because they have a layer 3 network.

    What happens is I either have to:

    1.  Create a NAT pool and have the 3rd party do NATting as well, which makes some troubleshooting fun for people not knowledgable about that second NAT.

    2.  Route to their network (192.168.1.0/24 and 192.168.2.0/24)

    #1 is easy and my current path forward.  Path #2 ends up - for the remote users at this site - taking 192.168.1.0/24 and 192.168.2.0/24 out of my ability to use those networks within my internal network at a later date.

    If I had a third option - i.e. the 192.168.1.0/24 and 192.168.2.0/24 networks are in a VRF (or Zone) or routed based on packet egress (i.e. I would always Source NAT out of the DMZ) then I could still use those networks on my internal corporate LAN without overlap.

    Long story short - I'm eliminating overlaps with creativity.  Having the route there along with users connected makes this interesting.  I could stand up a second pair of firewalls just for those users on-site - but that's a bit overkill.

Children
No Data
Unfiltered HTML