This would translate anything via the VPN to/from the addresses required. For example, anything destined to 172.18.11.5 will be translated to 192.168.1.5, and anything sourced from 192.168.1.5 will be translated to 172.18.11.5.
Just to confirm. We can create these proposals but executting these commands in the firewall? Then after we created them by these commands, we were now able to see them in the GUI, is that correct?
set ike p1-proposal pre-g5-aes256-sha preshare group5 esp aes256 sha-1 seconds 86400
set ike p2-proposal esp-aes256-sha1 esp aes256 sha-1 seconds 28800
And as for the NAT, nothing will be accessed on our side (192.168.1.0/24). We will be the one accessing their servers. So I think they (the client) would like to avoid the conflict at this IP range so they would like us to move to 172.18.11.0/24. As I understand it, looks like this can be done by the use of tunnel interface, then fixed IP range to 172.18.11.0/24 and Zone (VR) = Untrust (trust-vr), is this correct? Please advise.
Apologies for my late response. Im not sure I follow it correctly so I want to describe our requirements below where we are the site A.
Untrust IP of Firewall
Phase 1 Proposal
Phase 2 Proposal
Note: I just put 192.168.1.0/24 for Site B's LAN because they said there will be issues if we use this subnet.
Site B said there will be conflict/ issues if we use 192.168.1.0/24 so they would like us to NAT it to 172.18.11.0/24. Can you help me how to set this up or can you correct me if Im wrong? Because this is how I understand it.
This is going to be a route based VPN so we need to create a tunnel interface that will be set to Fixed IP (172.18.11.0/24). What will be the Zone (VR) for this tunnet interface? Is it better to create a new zone for this? Please advise.
You can create the tunnel interface as an unnumbered interface. Tunnel interfaces allow you to use any zone for the traffic, so that doesn't matter as long as you have policies in place for the unencrypted traffic.
You would need to create either a MIP (for one-to-one) or DIP (many-to-many) on the tunnel interface. This would allow the traffic to be translated before being encrypted.