Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 2 replies
  • Subscribers 40 subscribers
  • Views 17415 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

1-to-1 NAT over *internal* networks (LAN-to-LAN or LAN-to-DMZ)

BrianCarp

I'm trying to create proper policies for establishing NAT from one address in a non-public zone to one in a different non-public zone. For instance NAT that maps a LAN IP to one in the DMZ, or from one LAN to another, e.g. map 192.168.1.5 to 192.168.2.10.

I assumed the way to accomplish this was with a Business Application Rule, as with WAN-based NAT which I have implemented and which works as expected. However when I tried to use a similar rule to map a LAN address to one in the DMZ, with proper network policies already in place, the XG Firewall doesn't seem to want to do the translation. This is what I tried:

Source: Any
Hosted Server:
 * Source Zone: LAN
 * Hosted Address: {IP Host object in LAN} [e.g 192.168.1.5]

Protected Application Server(s):
 * Protected Zone: DMZ
 * Protected Application Server(s): {IP Host object in DMZ} [e.g. 192.168.2.10]
 * Forward all ports: ON

Routing:
 * Rewrite source address (Masquerading): OFF   {I have also experimented with ON+MASQ}

everything else: OFF

If this is not the correct way to do this and there is an alternate method that works, please enlighten me.

 



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

    From what I can gather from what you've said and the details you've given, you will have to turn masquerading on for this rule. Reason being is the IP Host object in the DMZ (assuming) is a /24 subnet so will refuse connections from the 192.168.1.0 subnet. To resolve this:

    Turn Rewrite Source Address on
    Create a new NAT Policy and set it to the internal IP address of the XG in the 192.168.2.0 /24 subnet.

    What you've already done probably is working but the packets aren't coming back or are being dropped by your computer.

    If the above doesn't work, turn on the Reflexive Rule slider, this will replicate the rule exactly in reverse. This may not work with rewrite source address turned on or you may have to set it to an IP that both devices can access.

    Hope that works!

Reply
  • 0

    From what I can gather from what you've said and the details you've given, you will have to turn masquerading on for this rule. Reason being is the IP Host object in the DMZ (assuming) is a /24 subnet so will refuse connections from the 192.168.1.0 subnet. To resolve this:

    Turn Rewrite Source Address on
    Create a new NAT Policy and set it to the internal IP address of the XG in the 192.168.2.0 /24 subnet.

    What you've already done probably is working but the packets aren't coming back or are being dropped by your computer.

    If the above doesn't work, turn on the Reflexive Rule slider, this will replicate the rule exactly in reverse. This may not work with rewrite source address turned on or you may have to set it to an IP that both devices can access.

    Hope that works!

Children
  • 0 in reply to Emile Belcourt

    Emile, I appreciate the suggestion, but unfortunately it does not work even with trying all of those things. I'm wondering if anyone has been able to make this work on their own XG setup.

    Hosts in the DMZ (or secondary LAN) subnet have no problem communicating with hosts in the primary 192.168.1.0 network; individual hosts can ping each other just fine, and accept connections. So regardless of whether an incoming connection was coming from the same subnet or a different one, it will be accepted because the proper policies and static routes (where appropriate) are in place.

    The issue seems to be with the XG agreeing to route the packets properly. In testing each of these options, I have run the "Packet Capture" in the System Diagnostics and can see that the ARP-NDP Request packets are consumed but no further packets are being forwarded (which is what would be happening if what I've already done was working but the packets were being dropped on the other side).

    What I want to happen is when a routing request comes in from anywhere on 192.168.1.0 for 192.168.1.X, the XG will capture that and translate it to 192.168.2.Y and forward the packets to that IP. It does not seem to want to do that, with the ways that I have been asking it to.

    As a final data point, if I change the Hosted Server:Hosted Address to 172.16.1.234 as a test (translating that to my 192.168.2.Y address), then everything works perfectly, exactly as expected. However when I change the Hosted Address back to a 192.168.1.X address it no longer works, regardless of what I select as the Source Zone. Is this a limitation of the route, a bug, or a misconfiguration?

Unfiltered HTML