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!
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
If I followed all that correctly, I have four concerns:
[ol]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
PCNSE
NSE
StrongSwan
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!
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.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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.
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
PCNSE
NSE
StrongSwan
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.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1692 | |
1087 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.