Source and Destination NAT over VPN

[Mike_P]

I have a Fortigate 30E that I am trying to get SNAT and DNAT working over a VPN tunnel to a Cisco 4331.

The LAN is a Registered public network that belongs to the company I work for, I will use 1.1.1.0/24 for this scenario.

I have created a site-to-site VPN tunnel with my local address as 10.209.253.0/255.255.255.0 and my remote address as 0.0.0.0/0.0.0.0.

I have created a Dynamic IP Pool Fixed Port Range with my External IP Range as 10.209.253.1 - 10.209.253.254 and an Internal IP Range as 1.1.1.1 - 1.1.1.254.

I created the IPV4 policy using the LAN as the incoming interface and the VPN as the outgoing interface and NAT to the Dynamic IP Pool of 10.209.253.1-254/24.

The VPN comes up and I am able to ping a loopback address on the Cisco 4331, 10.250.110.98 from a PC on the LAN of the 30E, 1.1.1.111.

I have verified that source address 1.1.1.111 is being translated to source-nat address 10.209.253.111 and thatthe destination address is 10.250.110.98.

The issue I am running into is the pinging from the Cisco 4331, 10.250.110.98 to the 30E 1.1.1.254, which is the LAN address of the 30E. After researching the Fortinet website, Google and Youtube, I found an article that I thought sounded like it would work.

I created a Virtual IP static NAT using the VPN interface with an External IP Address Range 10.209.253.1 - 10.209.253.254 and the Mapped IP Address Range of 1.1.1.1 - 1.1.1.254 and created a policy using the VPN as the incoming interface and the LAN as the outgoing interface and allowing all services and NAT is disabled.

Still cannot ping from 4331 to 30E.

Any help would be greatly appreciated!

[lobstercreed]

If I followed all that correctly, I have four concerns:

[ol]

You said "The issue I am running into is the pinging from the Cisco 4331, 10.250.110.98 to the 30E 1.1.1.254, which is the LAN address of the 30E", but you already explained that you're having to NAT everything 1.1.1.x to 10.209.253.x, presumably because the 1.1.1.x addresses overlap with something on the 4331's network.  So I guess the question is have you tried pinging 10.209.253.254 to get a response?

You also mentioned pinging the LAN interface on the firewall.  It's possible that you can ping other hosts on the LAN (again using their NAT'd IPs) while still not being able to ping the firewall if you don't have PING enabled in the Interface configuration, so double-check those things.

Is the far end (4331) configured correctly to route 10.209.253.0/24 to you across the VPN tunnel?  Now that I think again, it must be based on the fact that you can ping from a host on your LAN.

Lastly, and this may be of greatest importance, but I don't think you want the remote address on the FortiGate VPN to be 0.0.0.0/0  I'll be the first to admit I'm not very experienced with these configs, but I'm like 99% sure you need that to be the 10.250.110.98/24 network, and perhaps any others that exist on the remote LAN.  It may not affect the scenario you're describing but if I'm picturing this right you're going to send ALL Internet traffic down this tunnel the way you have it set up.  That sounds problematic to me, but perhaps that's normal.[/ol]

[emnoc]

The diag debug flow is your friend. 1st what do you show between the src/dst-subnets they should be the NAT's address/subnet and not the pre-NAT details

  diag vpn tunnel list | grep "src: \ dst:"

Look at src: dst:

What does the policy look like ( show firewall policy <###> )

What does diag debug flow  ( is it matching the policy, is a route found, is IPSEC involved ) 

Ken Felix

[Mike_P]

Lobstercreed and emnoc, thanks for the replies!

I will answer Lobstercreeds questions first.

1. From the 30E LAN 1.1.1.111 which translates to 10.209.253.111 and I can ping 4331 Loopback address 10.250.110.98. This brings up the VPN and I confirmed with the session list that 1.1.1.111 translates to 10.209.253.111.

2. The LAN interface is .254 and the PC is .111 neither of which is pingable from the 4331, I have verified that PING is enabled.

3. When the VPN establishes it receives a static route from the public IP the 30E is behind.

4. I have tried it both ways.

Ken,

I am in Tomball, TX, you are close.

I need to play around with the diags, debugs, or whatever Fortigate calls it.

This is a strange one.

If I put the 10.209.253.0/24 on the LAN and do not do the NAT I can ping the Fortigate from the 4331.

I am going to try and get some kind of drawing on here.

Thanks!

[Mike_P]

Attached is a drawing.

The VPN will only be brought up from the Fortigate, but once the tunnel is up it is necessary to be able to ping the appliance and nodes on the LAN from the 4321.

[sw2090]

hm from where to where is the tunnel?

Directly from the 4321 to the Fortigate?

If so you don't neccessarly need to do NAT. As long as the 4321 does have a route to the lan subnet of the FGT and the FGT does have a policy that allows traffic from vpn to lan you should be able to reach it.

You only might need NAT on the 4321 to have client behind it to go out with the correct subnet.

Without they would reach the FGT with their original LAN Ip which would require annother policy to work.

[Mike_P]

The LAN network needs to be hidden always. Multiple remote sites will use the same IP network for their LAN. The IP pool will change and that is was identifies that remote site. So the NAT needs to be bi-directional once the VPN tunnel is established.

[emnoc]

So I can really see or read the cfg, but what are saying from the cisco device loopback, the inter interface, etc,....

The fortigate is going to be simple fwiw but if the address are private on both side, what are you NAT into and why again must nat bet used?

And in the cisco crypto map you would put your post-NAT address in the ACL for the local and remote subnet that your fgt has that 10.209.253.1 range.

e.g 

 access-list ENC_DOMAIN line 1 extended  permit ip 1209.253.254 10.209.253.1

  crypto map outside match address ENC_DOMAIN

[sw2090]

Well then...

I have something rather similar. I have a service that has to be accessed via dial up vpn connections. This is however limited to the lan ip side of the FortiGate. 

So I made a policy allowing traffic coming in form dial up vpn and going to that service by doing dnat with an ip pool of the lan subnet. So the service will only see FGT Lan IPs connecting to ot. it won't see any net on the other side of the tunnel.

Of coure you could to that with a whole subnet too. 

My dial up tunnels have their own subnet anyways so don't need to care about what is clientside. Just there need to be routes. If I wanted to not have client subnet to go on via my FGT I#d have to do NAT in my policies.