Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
ashish_verma
Contributor
Jump to solution

NAT issue over VPN

Hello Mates,

 

 We are getting this issue in which the tracker is showing 2 logs for the same traffic (same source and destination port numbers) one is getting encrypted (and accepted) and with the same time stamp another one which is getting dropped at the external interface with reason of address-spoofing. Below are the details:

The source is 10.1.4.0/24 and is directly connected to CP firewall. The source is getting natted to IP 194.168.1.153 (subnet 194.168.1.x is not configured on any of the interface of this firewall. The VPN is configured with interoperable object and the tunnel are up. When initiating the traffic with source 10.1.4.233, in the tracker we can see the source is getting natted to 194.168.1.153 and also the traffic is getting encrypted. Just after this log ( with the same timestamp) another drop log is there with source 10.1.4.233, same source port and destination and getting reason is address-spoofing on eth2.530(external interface). On putting tcpdump on eth2.530 we are not getting any hit. 

On "fw monitor -p all", I can see the traffic (Syn) is passing through the firewall after getting translated, also receiving the reply back (Syn/Ack) to 194.168.1.153 but only i (Pre-inbound) after that no IoO. We have done manual hide nat configuration. 

Please let me know if any further info required. Thanks in advance.

 
 
0 Kudos
1 Solution

Accepted Solutions
Timothy_Hall
Legend Legend
Legend

The second log is an anti-spoofing drop based on the destination IP address which you have not revealed in your post.  What is the destination IP address and is it defined in the topology of an internal interface of your firewall?  It should not be.  You probably have the entire RFC1918 range defined as your internal firewall topology, yet the destination IP address for this VPN-bound packet is part of RFC1918 as well.  If you'd rather not adjust the firewall's internal topology (which is always a bit nerve-racking as you may suddenly run afoul of antispoofing in ways you aren't expecting), on the topology screen of the External eth2.530 interface populate the "Don't check packets from" option to set an antispoofing exception for this specific VPN traffic.

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

View solution in original post

3 Replies
Timothy_Hall
Legend Legend
Legend

The second log is an anti-spoofing drop based on the destination IP address which you have not revealed in your post.  What is the destination IP address and is it defined in the topology of an internal interface of your firewall?  It should not be.  You probably have the entire RFC1918 range defined as your internal firewall topology, yet the destination IP address for this VPN-bound packet is part of RFC1918 as well.  If you'd rather not adjust the firewall's internal topology (which is always a bit nerve-racking as you may suddenly run afoul of antispoofing in ways you aren't expecting), on the topology screen of the External eth2.530 interface populate the "Don't check packets from" option to set an antispoofing exception for this specific VPN traffic.

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
ashish_verma
Contributor
Thanks Tim for quick reply. The destination is 172.21.15.153. On anti-spoofing "Don't check packets from:" is not selected but the flow works for all the other destinations as many VPNs are configured on this firewall. However I will check by excluding this particular IP address from the spoofing.
0 Kudos
ashish_verma
Contributor
Many thanks Tim, it worked.
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events