Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
fferraro87
New Contributor II

NAT IP before enter in IPSEC tunnel

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

 

2 Solutions
Toshi_Esumi

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.

View solution in original post

emnoc
Esteemed Contributor III

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  

View solution in original post

PCNSE NSE StrongSwan
7 REPLIES 7
Toshi_Esumi
SuperUser
SuperUser

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.

emnoc
Esteemed Contributor III

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  

PCNSE NSE StrongSwan
fferraro87
New Contributor II

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"
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
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?

 

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

Toshi_Esumi

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.

emnoc
Esteemed Contributor III

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  

PCNSE NSE StrongSwan
fferraro87
New Contributor II

Thanks a lot, i've solved nat policy inbound and outbound because from remote site they want only public IP and not local. Thanks

BackerTheHacker

@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.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors