New Member

Question

Address translation to IPsec VPN

Forum|Forum|13 years ago
April 24, 2013
16 replies
12758 views

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.

rwpatterson

New Member

Welcome to the forums. I' ll bet your networks are 192.168.1.0/24... Personally, I would avoid monkeying around with Scotch tape and bubble gum trying to make things work when the real solution here is to change the IP schemes. (yes, both!) Once you spend a day or so taking care of that, then the rest will no longer be an issue. If you insist on leaving things well enough alone, then your only solution would be from the SSL VPN side to NAT the entire subnet to something different for one side. By creating an IP pool that covers the entire subnet, you would virtually change 192.168.1.x to 192.168.(2-255).x. For the record, we know you' re excited firing up your first networks, but you should always change the IP schemes provided from the manufacturers' default settings to ANYTHING else. That will avoid this exact issue down the road.

stenullAuthor

New Member

Thanks for answering. Well, i have lots of different internal networks. This is just a temp fix while we develop in some machines given to us from our client and would like to avoid changing ip on those. They just happened to have the exact same ip range as our offsite network (172.16.4.0/22). and its actually only 172.16.4.0/24 addresses that are interesting to reach from my office. I manage to do this with Virtual IP. But what i see now is that both 172.16.4.0/24 (old) and 172.16.48.0/24 (new) addresses reach my offsite network. Is there a mechanism in Virtual IP that i have overseen? I have IPsec VPN set up for this connection. Thanks again, appreciate you collaborating with me :)

rwpatterson

New Member

I could start working with you, but I have to leave the office and work off site today, so my Internet time will be minimal. How are the 2 networks connected? VPN I assume. If so, policy mode or interface mode VPN setup? By the way, 172.16.4.0/24 and 172.16.4.0/22 are not exactly the same networks... Also, where does 172.16.48.0 come into play?

stenullAuthor

New Member

Hi. Sorry for the delay. We are at different time zones and i had a day off yesterday.. Yes your assumption is correct, the 2 networks are connected via IPsec VPN. I don' t have IPsec Interface Mode enabled. Your right, 172.16.4.0/24 and 172.16.4.0/22 are not the same networks, what i meant was that only machines from 172.16.4.xxx is interesting for me to reach and not addresses from 5, 6 and 7 sub nets. 172.16.48.0/24 is the address range on my office that i want to translate to 172.16.4.0/24 for my VPN. and still be able to use 172.16.4.0/24 for machines on my office. Sorry if i express myself unclear, but as you probably have noticed, English is not my native language.

ede_pfau

SuperUser

The real question is: how does your office FGT know that there are 172.16.4.x hosts behind the tunnel? Otherwise, it would not be able to reach them there. So, it boils down to routing. I am assuming (as you haven' t mentioned yet): - the VPN is set up in " Interface Mode" - you have created a static route for the 172.16.4.x/22 subnet pointing to the tunnel interface This route has to be changed to the 172.16.48.x instead. If this route is missing the FGT will discard this traffic (or at least it should...).

stenullAuthor

New Member

Hi ede_pfau. I think i misunderstand " Interface mode" , but my VPN has IPsec Interface Mode disabled, and my FGT runs in " Switch mode" . We have no static route for the 172.16.4.x/22 subnet but there is a " Connected" route. I think it learned this because i had a policy that said " 172.16.4.x/22 go to this tunnel" . Am i right about that?

ede_pfau

SuperUser

OK, sorry, you already mentioned that your VPN is in Policy Mode. That makes routing a bit more complicated. The route to the remote network behind the tunnel is (automatically) set to the ' destination network' in the IPSec policy. I haven' t worked with Policy Mode VPNs for a long time but I think that your ' connected' route comes from this. Or do you have 172.16.4.x/22 assigned to any physical interface? If not it should suffice to change the destination address object in the IPSec policy to create the correct route (namely, 172.16.48.0/24).

stenullAuthor

New Member

Ah now i know where my connected route comes from, il try to paint our network for you. We have 3 Physical interfaces, internal, wan1 & wan2. wan1 is for our WMWare net and wan2 is for external traffic. I had setup 172.16.5.245 255.255.252.0 to wan1 as a secondary IP address. This route goes to wan1. My tunnel is setup on wan2. And looking closer in routing monitor i see that it gets routed to interface wan1. sorry for the confusion, my bad. if i remove this secondary ip from wan1 traffic to both 172.16.4.x and 172.16.48.x starts flowing trough my tunnel as 172.16.4.x. And if i add 172.16.5.245 255.255.252.0 to wan1 again both 172.16.4.x and 172.16.48.x stops working. No other routing is set up for this. So what im trying to achieve is: 172.16.4.x /22 goes to my wan1 interface, thats the simple part. 172.16.48.x /22 goes to my IPsec tunnel and get translated to 172.16.4.x /22 just before entering the tunnel.

ede_pfau

SuperUser

So you need 2 static routes on the FGT: 172.16.4.0 /22 pointing to wan1 172.16.48.0 /24 pointing to the tunnel oops, you cannot work with the tunnel as a port...policy mode! I would recreate the VPN in Interface Mode (tick the checkbox in phase1 when creating it, no way to revert this afterwards). Now you get a tunnel interface (= port) which you can use like any other port. The policy changes from action=IPSEC to action=ACCEPT. Then, you can set routes pointing to the tunnel interface. But even with Policy Mode IPsec you can make this work: specify the .48 subnet in the IPSEC policy as destination (create a new address for this). Check the routing monitor! What you did before when you assigned a secondary IP to wan1 is to auto-create a ' connected' direct route. Secondary IPs are a bad idea for several reasons, one of them being the side effects like this.

stenullAuthor

New Member

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

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!

rwpatterson

New Member

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.

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded