IPSec Tunel - no nat in outbound traffic

[intaq]

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!

[PhoneBoy]

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

[intaq]

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

[intaq]

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.

[the_rock]

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

Best,

Andy

[intaq]

diagram

[the_rock]

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

Andy

[intaq]

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

[the_rock]

This is what Im referring to...

Andy

VPN Communities - Advanced (checkpoint.com)

 

[spottex]

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.

[the_rock]

Super valid point.

[intaq]

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?

[the_rock]

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

Andy

[the_rock]

Can you check below, install policy and try?

Best,

Andy

 

[intaq]

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:

[spottex]

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

[intaq]

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

[the_rock]

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

[intaq]

Sure, I did it and no drops:

fw ctl zdebug + drop | grep peer_public

[spottex]

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.

[the_rock]

vs_0 does not mean its vsx, you see that on regular firewalls as well when you test vpn traffic. 

Andy

[spottex]

Usually I see it showing the VS it originates

edit: You made me second guess my self so went and checked 🙂
This VPN runs on Virtual Sys 2
[vs_2][fw_0] 28Mar2024 9:00:41.638615 wrp131:O[56]: 210.4x.x.x-> 61.x.x.x (UDP) len=108 id=7420

UDP: 500 -> 500

Edit 2: Re-read your reply - "you see that on regular firewalls"

Good point, but I thought I read in the post somewhere it was vsx. I think it is a separate post that I commented on.

[spottex]

Since the traffic is returning see if there is a log which may have a response from the peer to give a clue. filter on peer IP.
Or we debug.

And/or we figure out why the peer responds with source udp 1012

[the_rock]

No worries, I misunderstand stuff all the time LOL

Anywho, very good point about UDP 500

Andy

[AmirArama]

this fw monitor shows something is not valid.

when traffic is designated to the GW you should see only i, I. and then it should stop, the fact you see o,O on traffic designated to the GW itself, that means the GW doesn't recognize itself as the DST, so it attempts to route it back out.

i assume something is not configured properly.

as a start you should not configure any NAT, and you should just work with the link selection, select the source IP (bottom) and select the IP to which the peer should open the tunnel to (is your peer managed by the same MGMT? if not, configure the other peer to open tunnel to this same IP)

[the_rock]

All valid points, for sure.

Andy

[Robert_M_Nubile]

The peer is trying to reach the 129.0.10.1 or 10.0.1.212?

If it is trying to reach 129.0.10.1 you should set the link selection to Statically NATed IP and put the 129.0.10.1.

There is no need to create any NAT rule.

[intaq]

Hello guys:

As you say the incoming traffic arrives with a UDP port 1012, this is another added problem and we have notified the third-party.

Well, I don't really know how to explain what keeps happening with this issue. 

Previously the inbound traffic was NAT correctly to the external interface VIP:

[vs_0][fw_2] eth8:i[44]: public_peer -> my_public (UDP) len=404 id=51628
UDP: 1012 -> 500
[vs_0][fw_2] eth8:I[44]: public_peer -> vip_cluster_int_ext (UDP) len=404 id=51628
UDP: 1012 -> 500
[vs_0][fw_1] eth8:o[44]: public_peer -> vip_cluster_int_ext (UDP) len=404 id=51628
UDP: 1012 -> 500
[vs_0][fw_1] eth8:O[44]: public_peer -> vip_cluster_int_ext (UDP) len=404 id=51628
UDP: 1012 -> 500

But now and without making any change in the configuration, the incoming traffic is not NAT, managing it in a very strange way, it seems as if the FW does not know how to manage this traffic and therefore does not NAT it.

[vs_0][ppak_0] eth8:o[44]: public_peer -> my_public (UDP) len=404 id=46535
UDP: 1012 -> 500
[vs_0][ppak_0] eth8:O[44]: public_peer -> my_public (UDP) len=404 id=46535
UDP: 1012 -> 500
[vs_0][ppak_0] eth8:i[44]: public_peer -> my_public (UDP) len=404 id=46535
UDP: 1012 -> 500
[vs_0][ppak_0] eth8:I[44]: public_peer -> my_public (UDP) len=404 id=46535

As you can see on the FW monitor I see a difference in:

[vs_0][fw_1] when it works correctly.

[vs_0][fw_2] when it works correctly.

[vs_0][ppak_0] when it is not working properly.

And now drop is observed, when previously no drop was observed:

[Expert@BBVA_FW1:0]# fw ctl zdebug + drop | grep public_peer

@;3332954445;[kern];[tid_0];[SIM-241305849];do_cut_through: failed, dropping packet, simi_ip_forwarding_checks() failed, conn: <public_peer,1012,my_public,500,17>;

@;3332954445;[kern];[tid_0];[SIM-241305849];do_packet_finish: SIMPKT_IN_DROP vsid=0, conn:<public_peer,1012,my_public,500,17>;

@;3332960595;[kern];[tid_0];[SIM-241305849];do_cut_through: failed, dropping packet, simi_ip_forwarding_checks() failed, conn: <public_peer,1012,my_public,500,17>;

@;3332960595;[kern];[tid_0];[SIM-241305849];do_packet_finish: SIMPKT_IN_DROP vsid=0, conn:<public_peer,1012,my_public,500,17>;

I have tried I think everything, configuring NATs, inbound outbound, modifying the linkselection, reconfiguring everything. Even the inbound traffic is not showing up in the logs from the time it stopped performing NAT. I have balanced to node 2 and neither.

This case is already communicated to support.

As added information and regarding the outgoing traffic, we have replicated the scenario in a lab and we can see that the outgoing traffic is apparently having a normal behavior, not going out from the VIP but from the physical one NAT to the public one.

I will keep you informed as this progresses, thanks for your suggestions.

[AmirArama]

https://support.checkpoint.com/results/sk/sk162437

you see. what is going on is that you receive the connection to your public IP, your GW don't know how to handle it like it's not suppose to listen on this IP to ike, so it just send it out through his default route to your router, your router receives the packet and send it back to you, since the destination is your public IP, and you have routing loop, which end in expired ttl and the packet is lost which is the drop that you see.

the main issue here from what i understand, is that your GW for some reason doesn't think it should listen and process ike to his public IP. and the cause for that, should be looked into..