topic Re: IPSec Tunel - no nat in outbound traffic in General Topics

IPSec Tunel - no nat in outbound traffic

intaq — Fri, 22 Mar 2024 13:21:42 GMT

Hi mates!

I detail the problem, it is the first time I try to configure a tunnel in a ClusterXL in Open Server.

The external interface of the cluster has private addressing, my ISP allows the traffic without NAT, it sends or receives the traffic without modifying it.

So somehow I have to present my traffic with public addressing. I have tried to create a NAT rule but it does not work. Currently the traffic is arriving to my ISP with origin my private VIP from the external interface.

The tunnel is configured, in the linkselection my VIP from the external interface is selected.

Test:

1.- NO Nats configured:

[vs_0][fw_0] eth8:o[44]: ip_ext_phy_node1 -> peer_public_dst (UDP) len=200 id=1664
UDP: 500 -> 500
[vs_0][fw_0] eth8:O[44]: vip_ext_cluster -> peer_public_dst (UDP) len=200 id=1664
UDP: 500 -> 500
[vs_0][fw_0] eth8:o[44]: ip_ext_phy_node1 -> peer_public_dst (UDP) len=200 id=7197
UDP: 500 -> 500
[vs_0][fw_0] eth8:O[44]: vip_ext_cluster -> peer_public_dst (UDP) len=200 id=7197
UDP: 500 -> 500

2.- Nat Configured
src original: vip_ext_cluster

dst original: peer_public_dst

translated src: my_ip_public

[vs_0][fw_0] eth8:o[44]: ip_ext_phy_node1 -> peer_public_dst (UDP) len=200 id=28261
UDP: 500 -> 500
[vs_0][fw_0] eth8:O[44]: my_ip_public -> peer_public_dst (UDP) len=200 id=28261
UDP: 500 -> 500
[vs_0][fw_0] eth8:o[44]: ip_ext_phy_node1 -> peer_public_dst (UDP) len=200 id=29229
UDP: 500 -> 500
[vs_0][fw_0] eth8:O[44]: my_ip_public -> peer_public_dst (UDP) len=200 id=29229

As you can see, if I don't configure nat it doesn't nat with the public IP on my side.
If I configure nat it does nat but not from the virtual one, but from the physical one of the node (This differs from the IP selected in linkselection)

At this point my question is if there is a way to nat my outgoing traffic from the VIP configured in the linkselection or as a solution I have to create an interface and configure the public IP and modify the linkselection. Or is there a step that I am missing?

Thanks!

Re: IPSec Tunel - no nat in outbound traffic

PhoneBoy — Fri, 22 Mar 2024 15:19:39 GMT

Just to be 100% clear, you're trying to NAT traffic that is originating from the gateway specifically? (not some host behind it)

Re: IPSec Tunel - no nat in outbound traffic

intaq — Fri, 22 Mar 2024 16:14:30 GMT

Yes, I’m trying to present my outgoing traffic (from the gateway) with an IP public (with NAT) to stablish an IPsec tunnel.

Re: IPSec Tunel - no nat in outbound traffic

the_rock — Sat, 23 Mar 2024 01:28:53 GMT

I think a simple network diagram would help us understand this better.

Best,

Andy

Re: IPSec Tunel - no nat in outbound traffic

intaq — Sat, 23 Mar 2024 02:06:12 GMT

Yes, I am trying to nat traffic that is presented with the IP set in the linkselection (the VIP of the external interface) but I only can nat if the source is the physical ip of the gateway not the VIP.

Re: IPSec Tunel - no nat in outbound traffic

intaq — Sat, 23 Mar 2024 02:09:19 GMT

diagram

Re: IPSec Tunel - no nat in outbound traffic

the_rock — Sun, 24 Mar 2024 13:01:08 GMT

Just make sure NAT is NOT disabled inside vpn community and then create nat rule to reflect the change you need.

Andy

Re: IPSec Tunel - no nat in outbound traffic

the_rock — Sun, 24 Mar 2024 13:19:13 GMT

This is what Im referring to...

Andy

VPN Communities - Advanced (checkpoint.com)

Re: IPSec Tunel - no nat in outbound traffic

intaq — Mon, 25 Mar 2024 08:39:17 GMT

This option is checked and NAT tests were performed like that.

Re: IPSec Tunel - no nat in outbound traffic

spottex — Mon, 25 Mar 2024 21:29:19 GMT

Review the following settings:

GW Cluster properties > IPSec VPN > Link Selection > Source IP settings (Button)
"When intiating a tunnel use the following IP Address..."
Set to Manual: > Main IP Address or Select address from Topology table.

Re: IPSec Tunel - no nat in outbound traffic

the_rock — Mon, 25 Mar 2024 22:59:05 GMT

Super valid point.

Re: IPSec Tunel - no nat in outbound traffic

intaq — Tue, 26 Mar 2024 10:29:40 GMT

I have tested the change and it remains the same.

This is my main doubt:

Is this behavior normal?
- Outbound traffic:
Physical IP of the node > (nat) Public IP => Peer Public

Incoming traffic:
Peer Public => Public IP > (nat) VIP

What I mean is that the IP with which the traffic originates to establish the tunnel is different from the IP with which the traffic is received. In both cases it would have to be with the VIP, right?

Re: IPSec Tunel - no nat in outbound traffic

the_rock — Tue, 26 Mar 2024 11:29:54 GMT

I think I have a feeling what issue could be...will send you screenshot later.

Andy

Re: IPSec Tunel - no nat in outbound traffic

the_rock — Tue, 26 Mar 2024 14:30:43 GMT

Can you check below, install policy and try?

Best,

Andy

Re: IPSec Tunel - no nat in outbound traffic

spottex — Tue, 26 Mar 2024 19:07:10 GMT

I just reviewed one of our firewalls with an internal VPN using 'Source IP settings (Button)' and yes it still using the vip of the egress interface.
I had to sit and think why we had to do this and now remember. It adds an ID in the auth packets with the 'Source IP settings (Button)' config. The ID needed to match the alternative IP configured in the VPN certificate for the auth. So this wont help.

So now if the setting the_rock mentions does not work...
My thoughts are:
The packet needs to leave with the source of the interface for the traffic to return there.
It should leave with the VIP IP or the NAT as it is doing.

The VIP IP needs to be routable back to the ISP from the internet so your ISP will need to advertise it.

The ISP needs to route your VIP back to your fw.

Your VIP needs to be on the correct network or another interface and/or accept ARP for the public ip

In your capture we don't see return traffic .

Check your fw for ARP requests and it is replying: tcpdump -nni eth8 arp host <public ip>

If not try to edit your local.arp for the FW or vFW and push policy. Or use gratuitous ARP.

Or the NAT needs to happen at the ISP and you have NAT-t enabled

Re: IPSec Tunel - no nat in outbound traffic

intaq — Wed, 27 Mar 2024 11:31:23 GMT

Now I can't connect to the computer to post a screenshot but I don't have that option, I checked it before and I don't have that check.

Thanks!!

edit:

Re: IPSec Tunel - no nat in outbound traffic

intaq — Wed, 27 Mar 2024 11:35:23 GMT

The return traffic works, only in the trace I attached only destination.

PPAK 0: Get before set operation succeeded of fwmonitor_kiss_enable
[vs_0][ppak_0] eth8:i[44]: peer_public -> my_public (UDP) len=404 id=51628
UDP: 1012 -> 500
[vs_0][fw_2] eth8:i[44]: peer_public -> my_public (UDP) len=404 id=51628
UDP: 1012 -> 500
[vs_0][fw_2] eth8:I[44]: peer_public -> vip_cluster_int_ext (UDP) len=404 id=51628
UDP: 1012 -> 500
[vs_0][fw_1] eth8:o[44]: peer_public -> vip_cluster_int_ext (UDP) len=404 id=51628
UDP: 1012 -> 500
[vs_0][fw_1] eth8:O[44]: peer_public -> vip_cluster_int_ext (UDP) len=404 id=51628
UDP: 1012 -> 500
[vs_0][ppak_0] eth8:i[44]: peer_public -> my_public (UDP) len=404 id=20144
UDP: 1012 -> 500
[vs_0][fw_2] eth8:i[44]: peer_public -> my_public (UDP) len=404 id=20144
UDP: 1012 -> 500
[vs_0][fw_2] eth8:I[44]: peer_public -> vip_cluster_int_ext (UDP) len=404 id=20144
UDP: 1012 -> 500
[vs_0][fw_1] eth8:o[44]: peer_public -> vip_cluster_int_ext (UDP) len=404 id=20144
UDP: 1012 -> 500
[vs_0][fw_1] eth8:O[44]: peer_public -> vip_cluster_int_ext (UDP) len=404 id=20144
UDP: 1012 -> 500

Re: IPSec Tunel - no nat in outbound traffic

the_rock — Wed, 27 Mar 2024 11:50:53 GMT

Can you do zdebug to see if that IP is dropped anywhere?

Re: IPSec Tunel - no nat in outbound traffic

intaq — Wed, 27 Mar 2024 11:53:16 GMT

Sure, I did it and no drops:

fw ctl zdebug + drop | grep peer_public

Re: IPSec Tunel - no nat in outbound traffic

spottex — Wed, 27 Mar 2024 19:33:25 GMT

OK that moves us on a bit. Two things...

The traffic is showing on vs_0. Is the VPN created in the policy of a virtual firewall or the VSX policy?

The return traffic should be UDP: 500 -> 500 so once your end is sorted and this still happens you will need to look at the other end.