NAT' ing within a VPN tunnel

[#1]

We have been asked to setup a VPN tunnel between ourselves and a 3rd party to us. They will be providing access to an application over this tunnel. The tunnel is no problem for us to setup however, the internal ip range we currently use is already in use by them at their end or overlaps a current range of theirs. I was wondering if it were possible to NAT traffic inside a tunnel on an F310b so we could use a completely new ip list and then NAT that to our users/servers etc. We both use a 10 range internally and they have asked if we could use a 192 range and then NAT that to our 10 range. We have obviously had thoughts about using VIPS but can VIPS be used inside a VPN tunnel? Any help would be very much appreciated.

[rwpatterson]

Welcome to the forums. If you create a tunnel in interface mode, then yes, it can be done. Two policies will have to be created though: * One for inbound traffic with that VIP defiunition * A second for outbound traffic with an IP pool The reason for two is that depending on which side starts the transfer, that policy will get the traffic to/from the tunnel. If the traffic is one way, the you will only need one.

[willem]

This can also be done without using interface mode, just enable outbound NAT on your encrypt policy, use the command " set natip" on your policy and the command " set use-natip disable" on your tunnel. It works fine, we use it for a lot of our customers.

[#4]

Willem Your level of expertise on these is obvioulsy far greater than mine - could you please tell me in detail how I go about doing what you said on our Firewall - we have v4.2 on a 310b. many thanks for your help. Andrew

[ede_pfau]

Hi, take a good advice and configure your tunnel in interface mode. All it takes is to check the " interface mode" option box when creating the phase1. Then you obtain a new interface (Network>Interface) by the name of the phase1. You can handle that like any other interface or port: policy, NAT, VIP, routing,...you name it. The concept is so clear and straightforward it outshadows policy based VPNs by far. My personal opinion is that things that I don' t understand might work at first if I follow detailed instructions to the point. But then one little deviation of the documented setup, and I will go hunting the error near forever - just because I don' t understand the concept. And one of the best hidden concepts in this world is the policy based VPN from Fortinet. Now, religious part over. What you are setting up is a common scenario. As such Fortinet has documented the steps in the IPSec VPN Handbook on http://docs.fortinet.com. For 4.00MR2 see pages 40-44 " How to work with overlapping subnets" . The last 2 pages even show the detailed configuration for policy based VPN' s.

[willem]

Hi Andrew, I partially agree with Ede, when starting with Fortinet it' s a good idea to configure your tunnels in interface mode, it' s easier to work with. So in your case his advice is certainly correct and you would better reconfigure your VPN in interface mode. I don' t agree with his statements that policy based VPN is totally outshadowed by interface VPN or that it' s concept is hidden/difficult, therefore I will answer your question too: You need a few things to get this working with policy based VPN: 1) in the GUI, check the box for outbound NAT in your VPN policy. 2) in the CLI, edit that same policy and add the line " set natip x.x.x.x y.y.y.y" where x.x.x.x is the network address and y.y.y.y the subnet mask. 3) in the CLI, edit phase 2 of your VPN tunnel configuration and add the line: " set use-natip disable" This will give you the same result as natting on interface mode, but because it' s CLI based it' s less obvious and as I said before: if you' re not used to work with the CLI, following Ede' s advice and configuring interface mode so you can do everything in the GUI would be a better idea. Kind regards, Willem

[FortiRack_Eric]

Right on the spot Willem, Very good answer. I do favor interface mode IPsec. As it supports OSPF over the VPN and it has more routing capabilities, on top of the more self explanatory configuration. I.e. if you have to configure a dialup-vpn to internet connection you get something like this wan1 all wan1 dialup segment inbound-nat allow-inbound brrrr.... not so obvious. Cheers, Eric

[willem]

Eric, both have advantages and disadvantages, I' ve got a customer with over 250 VPN' s, if you enable interface mode there, the amount of subinterfaces and the routing table would just grow too big to work with. I always try to use the most suited mode for the environment I' m working in, but I have to agree that interface mode is certainly more self explanatory. Anyway, that' s not the discussion here, let' s see wether we helped Andrew out to fix his issue or if he needs some more hints from us. Kind regards, Willem

[#9]

Guys The more I read the more I get confused. I' m happy setting up a normal vpn tunnel however on this occasion I' ve read the IPSEC VPN' s about overlapping subnets but the config example they gave is for where you have VIPs at either end. My problem again is ... a supplier of ours needs to access a complete range of private ip' s on our system so lets say 10.66.0.1 to 10.66.0.254. Their internal range is 10.1.0.0/22. They have asked us to NAT our network and suggested 192.168.23.38 to 192.168.23.49. I think I have to create a VIP for this so have created a vip from the 192. range they suggested to our 10.66 range. My problems start when I try to create policies as I am not sure what rules with NAT applied etc I need or do I create to VIP' s one for inbound and one outbound. Thanks for the help so far Andy

[ede_pfau]

In your case you only need one VIP, many-to-many. The example I hinted at applies for the situation where both networks share the same IP range. This is not the case here. You define a VIP (as you probably did) on the wan interface, name: xxx external IP: 192.168.23.1 <== mapped to IP: 10.66.0.1 AND ending at 10.66.0.254 static NAT port forwarding: no this way, every mapped IP from the internal subnet is mapped onto the 192.168. subnet. Added benefit: if one of your hosts (e.g. 10.66.0.40) originates traffic to the supplier' s subnet like in ' ping 10.1.0.5' the VIP will take care of your (original) source IP and substitute the 192.168.23.40 for it. Now your only policy will be: from tunnel_interface, supplier_subnet to internal, VIP (!) service=... action=ACCEPT where supplier_subnet is an address defined as ' 10.1.0.0/22' .