Virtual IP inside VPN tunnel??!

I am doing this, and until I get a sniff of VPN/NAT capabilities (that are said to have more complex models especially for NAT) with FortiOS 3 - I thinkthe way I am doing it is the most elegant way with a single platform and with no participation in the arrangements from the other end of the tunnel. However there may be other ways of doing this that I didn' t test due to the broad scope of the required solution. My requirements were to act as a VPN concentrator for one remote VPN end point (cisco IOS VPN IPSec - hardware accelerated) and to alter the source and destination IP address most of the time (sometimes leaving the remote VPN traffic source IP the same and sometimes leaving their targetted host the same, per policy). Two virtual-domains. These are firewall policy/router/NAT contexts for want of a better description out of the manual. Break your port capability into four discrete ports for this one application. Pair them up. {Internet}---WAN2(vdom1)DMZ1----WAN1(vdom2)Internal----{Datacentre}-host __________|{S I N G L E F O R T I G A T E C H A S S I S}| Land the VPN on context 1 (root). The policy will be to encrypt from DMZ1 to WAN2 and the encryption relationship will probably be to a static peer with routeing to match the parameters at the far end (same networks and masks). I like a policy for each flow that is important and then a policy for everything else that might be conveyed - this helps if you later need to use QoS rate limiting in either direction. Route to the Virtual IP by pointing to the WAN1 IP address. DMZ1 and WAN1 being created from their own stub subnet so that they can unicast eachother and pass traffic through upon (route). Then present DMZ1 with a virtual-IP on vdom2 (I call mine " NAT" ) on the interface WAN1, which then points back to your real server. I also choose to change the source address of the extranet peer to hide the subscribers behind the IP address of Internal. The accounting data is collected on the fortigate, not the host. So I don' t need real IPs hitting the host and this makes multi-homing to the Internet that bit easier. The great pity being that the packets have to leave the firewall twice - so there is serialisation delay that wouldn' t occur if a logical interface could be created that was derived by a memory segment (with interprocess/device communication). However all the ports on my FortiGates operate at the same speed - and the device is not loaded. So the latency and risk of packet loss is of no consequence. Now if the FortiOS VPN paths were notional interfaces and not encyption modes applied to physical interfaces..... then your choice would be simple. It' d be nice if we could promote the associated VPN policy definitions into notional interfaces.... Maybe FortiOS 3.1.... ?

Yes you nedd enable NAT outbound on encrypt policy, on CLI you need insert config firewall policy edit <number> I don´t remember know exactly -> set natip x.x.x.x x.x.x.x f.e: 10.10.1.0 255.255.255.0 Then if you have internal IP 192.168.1.3 when you go out you IP set to 10.10.1.3 192.168.1.5 -> 10.10.1.5 192.168.1.26 -> 10.10.1.26 .......... Find " IPSec VPN with outbound NAT for overlapped subnets" on Knowledge Center for more reference. bye