Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 27 subscribers
  • Views 753 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 SNAT v18.0.4 MR-4

apijnappels

I have found a couple of old thread about this but cannot find how to do this. Even watched the video from the link in V18 but that didn't help me a lot either.

What I want to achieve is the following:

Traffic from 10.242.12.0/24 (SSL VPN client pool) connecting to 10.23.1.0/24 (VPN IPSEC site-to-site) network should be sourcenatted with 192.168.21.0/24 (Internal network of XG).

I have tried the following with a Linked NAT Rule from a firewall rule:

As far as my knowledge goes I should make a network object under Tranlsated Source with 192.168.21.0/24. Creating of the network object works without hassle, but the only objects that are to be found are hostobjects. Seems network objects are not possible to pick.

Then I tried to create just the NAT rule from NAT rules like this:

But here the same problem arises that I cannot add a network object to the Translated Source.

How can I make the 1-1 SNAT work?



This thread was automatically locked due to age.
Parents
  • 0 in reply to LuCar Toni

    I'm afraid both articles are not exactly what I need.

    The first article is more similar to what we need, to have SSL clients reach the other side of a IPSEC connection without altering the IPSEC connection. However, this only NATs the source to a single IP-address. As far as I have tried it is not possible to NAT the Source to a network rather than a single host.

    In the second article it indeed looks like a complete network is source natted from within the IPSEC connection. That is the right type of NAT but at the wrong place unfortunately. 

  • 0 in reply to apijnappels

    Policy based IPsec is limited to this SNAT (within the IPsec tunnel).

    Route based VPN can work with the NAT Page for MASQ. 

  • 0 in reply to LuCar Toni

    Too bad, had really hoped with all the improvements in v18 that the product would at least match UTM at every point. 1:1 NAT in UTM is so easy to configure that it is hard for me to understand why this is so much harder if possible at all in XG...

    Thanks for your input anyways. Really appreciate it.

  • 0 in reply to apijnappels

    Policy based VPN is somesort the old school of handling IPsec. Hence those limitations. I would prefer to move to Route based VPN. If not possible or the other appliance is a SG, you could also move to RED site to site, which also can use the NAT table. 

    Policy based VPN as a VPN technology has plenty of limitations. Starting with restarting the tunnel, if editing Local/Remote subnet, the management of plenty of tunnels and/or multiple SAs etc. 

  • 0 in reply to LuCar Toni

    I'm aware of the shortcomings of policy based VPN. Unfortunately much of todays connections are still policy based, even connections we have to some really large companies.

    SG had this perfect option where a 1:1 NAT was really quick and easy to configure. I'm sure we will find a solution somehow but stepping back when you expect to step up is always painful Cry

  • 0 in reply to apijnappels

    Personally, i would rather step back from 1:1 NAT in the first place, as this lead always to confusing Networks. Likely its used between a Big vendor, which assigns networks to each and everybody, but they likely use route based, if offered or its used because of duplicated networks (same network range etc.). Both requirements could be easily solved by other approaches (use route based or rethink your network and not invest more time on such bad design in the first place). 

    The SG solution with the checkbox about NAT was a workaround to get this done, as NAT also did not apply on IPsec traffic (due the limitation of policy based VPN). I cannot remember, which version implemented this checkbox, but its "rather new compared to the 21 years UTM". 

Reply
  • 0 in reply to apijnappels

    Personally, i would rather step back from 1:1 NAT in the first place, as this lead always to confusing Networks. Likely its used between a Big vendor, which assigns networks to each and everybody, but they likely use route based, if offered or its used because of duplicated networks (same network range etc.). Both requirements could be easily solved by other approaches (use route based or rethink your network and not invest more time on such bad design in the first place). 

    The SG solution with the checkbox about NAT was a workaround to get this done, as NAT also did not apply on IPsec traffic (due the limitation of policy based VPN). I cannot remember, which version implemented this checkbox, but its "rather new compared to the 21 years UTM". 

Children
No Data