Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
stenull
New Contributor

Address translation to IPsec VPN

Hi all. New member here and fairly new to the forti world so please bare with me if im missing something obvious :) I have a fortigate 60C in my office and one offsite for remote access. I have IPsec VPN set up between them and working splendid. Now to my trouble, we had to add a bunch of machines on my office that is on the same subnet as the offsite network... My idea was to get a " new sub net" internally and have that translated the offsite sub net just before entering the tunnel. So what i did was to add a new Virtual IP with the settings: External Interface: internal External IP Address/Range: my " new sub net" Mapped IP Address/Range: Offsite sub net I then went to the policy that before allowed connection from my internal net to offsite VPN and changed Destination Address to my new Virtual IP.. The effects, i can now connect to my offsite machines with both sub net addresses... What am i missing out here. i obviously want the " old sub net" to stay at my office and i can' t find anywhere any allowance for the " old sub net" to my tunnel... Im continuing to study the manual and if any of you have a nice pointer or advice it is highly appreciated.
25 REPLIES 25
stenull
New Contributor

Thanks for elaborating with me ede_pfau! I really appreciate it! Ok, i tested to set .48 subnet in my IPsec policy as destination,, but it didn' t show up in routing monitor at all.. Sound like Interface mode is the easiest way to go. If i recreate my VPN in Interface mode, do i need to do that in both ends, at office FTG and offsite FTG, or is that only a local setting? And where do you recommend me to put the address translation. The net on the other side of my tunnel is 172.16.4.x /22
ede_pfau
SuperUser
SuperUser

You only need to recreate the VPN tunnel on one/your side, and I would really recommend it. You configure NAT just the same way you would do it for a regular (wire) connection. For destination NAT, you use a VIP and specify it as the destination in the policy. That should be the same as in your current policy. Remember to switch the ACTION from IPSEC to ACCEPT!
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
rwpatterson
Valued Contributor III

ORIGINAL: ede_pfau Remember to switch the ACTION from IPSEC to ACCEPT!
Actually when you go to recreate the policy, the tunnel will not appear under the ' IPSEC' drop down any longer, so accept is the way to go.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
stenull
New Contributor

I changed my VPN to Interface mode. In my policy i changed destination interface to my tunnel interface and just to check that my tunnel works i add 172.16.4.0/22 as destination address. I bring up the tunnel and it goes green I then setup a static route saying 172.16.4.0/22 and point to my new tunnel interface. Now its possible to RDP and ping machines on the other side, the tunnel works. Ok now i just need the translation part to work. I have my VIP setup just like before
 External Interface: internal
 External IP Address/Range: 172.16.48.1 - 172.16.48.90
 Mapped IP Address/Range: 172.16.4.1 - 172.16.4.90 
 
Then in the policy i change destination address to my VIP. If i don' t change the static route at this point i can RDP successful with 172.16.48.x and not with 172.16.4.x. Changing the static route to 172.16.48.0/22 and point it to my tunnel interface and then it stops working again. am i using the VIP in the wrong way?
rwpatterson
Valued Contributor III

Instead of changing the static route, add a second for the .48 traffic. The FGT needs to know where the .4 traffic goes, but the LAN user needs to know where the .48 traffic goes, so both are required.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
stenull
New Contributor

Instead of changing the static route, add a second for the .48 traffic. The FGT needs to know where the .4 traffic goes, but the LAN user needs to know where the .48 traffic goes, so both are required.
But only one the .48 route is required to make the translation-tunnel part to work, or? Added route for 172.16.4.0/22 to wan1 and 172.16.48.0/22 is still routed to Tunnel interface, traffic still not finding its way..
ede_pfau
SuperUser
SuperUser

ya ya, routing can be challenging... You just want to route part of the .4 subnet to the tunnel. Use this route: 172.16.4.0/25 tunnelIF and 172.16.4.0/22 wan1 Hopefully this won' t clash but I' m confident here. This will route 172.16.4.1 - 172.16.4.127 to the tunnel and all the rest of wan1. (Now let' s pray that you don' t need .4.91-.4.127 on wan1...)
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
rwpatterson
Valued Contributor III

ORIGINAL: ede_pfau 172.16.4.0/22 wan1
You can' t route those RFC addresses to the Internet (unless something has changed...).

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
ede_pfau
SuperUser
SuperUser

wan1 is internal, not internet. wan2 goes out to internet. See his post above (" Ah now i know..." )
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
rwpatterson
Valued Contributor III

" Ah now i know..." has so many meanings....

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors