Hi,
i'm trying to create an ipsec tunnel everything it's fine.
Tunnel is up correctly, both phase1 and 2 are correctly done.
But from remote side, they ask me that they want that i've to translate my local IP before enter in the tunnel. So i've find that cookbook http://kb.fortinet.com/kb/viewContent.do?externalId=FD33638 So i've deleted old VPN (i've done it in interface mode) and create a new one with policy mode in order to follow that cookbook. But now with same settings (remote gw,local and remote address,ike version, encryption, auth etc etc) but in policy mode it doesn't work anymore.
i've error in phase1, so there is a way to nat my local ip before entering tunnel in interface mode? Thanks
Solved! Go to Solution.
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.
No. VPN is a tunnel to carry packets from a private range like 192.168.x.y to another private range over internet (public IP networks). Arn't "ProdHost" and "TestHost" in private range like 192.168.4.x? I thought the destination hosts are expecting to see your packet with a specific source private IP like 192.168.3.254, or similar.
The question is what the remote end is expecting to see as the source IP.
If he's masking the private scope behind the 5.149.124.28 than he should be good and the remote needs to have his proxy IDs showing 5.149.124.28 and if not so obvious a static route for this dst-subnet in the table
Guessing, I'm betting either one or both
Lack of policy at the far end
or
lack of static route at the far-end for 5.149.124.28
If you can confirm the far-end device gateway for the proper static routes and policy and diagnstics, you should easily find the issue(s).
Ken
PCNSE
NSE
StrongSwan
I assume your working VPN is route(interface)-based IPsec, not poloicy-based. I wouldn't change it to make just SNAT work. This KB seems to be quite old based on 4.0.
It should be quite simple with ineterface-based IPsec because it has an virtual interface to route a particular traffic to after SNAT is processed as long as the replaced source IP is a part of phase2 traffic/quick mode selectors. You need to define an IP Pool(ippool) with the IP(s) to replace the source IP with, and use it in a new policy in the NAT config section while you specify source/destination as you regularly specify, but outgoing interface is the IPsec interface. Then place it above the existing vpn policy for all other tunnel traffic. That should work as you expect.
Make sure to use the POST-NAT address in the phase2 proxy-ids if that is NOT clear, but the setup is simple. Also keep in mind you can use RT-based vpn with DNAT and even egress interface PAT. The 3rd advantage since it's a "interface" you can diag sniffer packet the interface for reviewing traffic
YMMV but RT-base is the way to go ;)
PCNSE
NSE
StrongSwan
Thanks for your answer, so now i've setting vpn (interface mode) ipsec. On phase 2 i've used natted ip (my public) on local address. i've also set policy but i cannot receive any response from remote side :
# diagnose sniffer packet "VPN 1"From remote side tell me, like i said on first post, that i've to nat ip before enter tunnel, but i see that every packet is natted correctly before entering tunnel. Am i wrong?
interfaces=[VPN 1]
filters=[none]
pcap_lookupnet: VPN 1: no IPv4 address assigned
50.231373 5.149.124.28 -> 185.85.58.4: icmp: echo request
54.987501 5.149.124.28 -> 185.85.58.4: icmp: echo request
59.987352 5.149.124.28 -> 185.85.58.4: icmp: echo request
70.905266 5.149.124.28.51894 -> 185.85.58.4.80: syn 1186440282
73.909047 5.149.124.28.51894 -> 185.85.58.4.80: syn 1186440282
79.908920 5.149.124.28.51894 -> 185.85.58.4.80: syn 1186440282
6 packets received by filter
0 packets dropped by kernel
That's my configuration for that VPN :
PHASE 1
edit "VPN 1"
set interface "wan1"
set ike-version 2
set nattraversal disable
set proposal aes256-sha256
set dhgrp 14
set remote-gw 185.85.57.2
set psksecret ENC IHRvbxtQN9lrGx/LEuQVRuetPiXrlQTebUtKasdRWWQTSRDFONT3lop8lJSkeMawlNWNnwi0qdUjj2k7rNOPzCKDbuHUKhHSeHvuTzsbXkrCBI+CPbmvUBlCU967AzSvgTp1qtQinqqXsSnAFqZpT2FQ9JMjqo/EbJdVg==
next
PHASE 2
edit "TEST DMZ"
set phase1name "VPN 1"
set proposal aes256-sha256
set dhgrp 14
set src-addr-type ip
set dst-addr-type ip
set keylifeseconds 3600
set src-start-ip 5.149.124.28
set dst-start-ip 185.85.58.4
next
STATIC ROUTE
edit 3
set dst 185.85.58.4 255.255.255.255
set device "VPN 1"
next
POLICY
edit 15
set uuid 008f4b52-a458-51e8-855b-d6b86503b07c
set srcintf "internal3"
set dstintf "VPN 1"
set srcaddr "192.168.3.10"
set dstaddr "ProdHost" "TestHost"
set action accept
set schedule "always"
set service "ALL"
set nat enable
set ippool enable
set poolname "SNAT 192.168.3.10"
next
edit 14
set uuid b0244456-a457-51e8-3374-9b19d707d386
set srcintf "VPN 1"
set dstintf "internal3"
set srcaddr "ProdHost" "TestHost"
set dstaddr "192.168.3.10"
set action accept
set schedule "always"
set service "ALL"
next
where IPPOOL "SNAT 192.168.3.10" translate 192.168.3.10 (local ip) to 5.149.124.28
No. VPN is a tunnel to carry packets from a private range like 192.168.x.y to another private range over internet (public IP networks). Arn't "ProdHost" and "TestHost" in private range like 192.168.4.x? I thought the destination hosts are expecting to see your packet with a specific source private IP like 192.168.3.254, or similar.
The question is what the remote end is expecting to see as the source IP.
If he's masking the private scope behind the 5.149.124.28 than he should be good and the remote needs to have his proxy IDs showing 5.149.124.28 and if not so obvious a static route for this dst-subnet in the table
Guessing, I'm betting either one or both
Lack of policy at the far end
or
lack of static route at the far-end for 5.149.124.28
If you can confirm the far-end device gateway for the proper static routes and policy and diagnstics, you should easily find the issue(s).
Ken
PCNSE
NSE
StrongSwan
Thanks a lot, i've solved nat policy inbound and outbound because from remote site they want only public IP and not local. Thanks
@fferraro87 I know this post is really old but wondering if you still remember the fix you had for this or was it the above config you shared? Thank you.
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 |
---|---|
1665 | |
1077 | |
752 | |
446 | |
220 |
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.