Gateway is natting using interface IP for GTW to MGMT communication

[an_technical]

Hi All,

I hope you are doing well.

The issue I am facing is that my GTW A is not able to communicate with the MGMT server sitting in a different location. There is mpls connection between GTW A and the MGMT server. When we ping the MGMT server from GTW A, it nats to mpls interface ip and sends traffic to the other site. Ideally, this should not happen. We created no nat rule at the top, but the issue is there.

GTW A: 10.1.12.22

MPLS IP on GTW A: 10.1.92.3

MGMT Server: 10.1.85.200

GTW A--> (MPLS) ---> DC GTW --> MGMT SERVER

On MGMT SERVER, in tcp dump,  I see traffic is coming from 10.1.92.3

There is no route on the DC MPLS router for 10.1.92.3 to send reply traffic to Site A.

Anyone face this issue?

[the_rock]

Do you have this setting enabled on mgmt?

 

[an_technical]

Hello @the_rock : This setting is not enabled.

[Martijn]

Hi,

What is the route on GTW A to reach the MGMT server?

Looking at "GTW A--> (MPLS) ---> DC GTW --> MGMT SERVER" the route on GTW A to the MGTM server is via the MPLS network.
So a PING will leave the MPLS interface on GTW A and thus source IP is 10.1.92.3.

Is IPSec involved? Is there a tunnel between GTW A and DC GTW over which the MGMT traffic is send?

Regards,
Martijn

[an_technical]

Hi @Martijn : Yes route on the firewall to send traffic to the MGMT server is through the MPLS interface.

MGMT traffic is over the MPLS link, not ipsec tunnel.

[Martijn]

Hi,

So if the route on the firewall towards the management server is on the MPLS (Internal) interface it is normal behaviour the firewall will us this interface as the source interface (and thus source IP) for traffic the firewall initiates to the management server. Just like @emmap mentions.

The IP-address configured on the firewall object (maybe in your case 10.1.12.22) is only administrative. The Gaia OS will use standard routing to reach a destination.

From the information you provided all is working fine and there is no NAT-ing involved. Just basic routing. But maybe I missed something.

When running 'tcpdump', you see the MPLS IP. Can you also try "fw monitor'. It will show more details and you can check the NAT-ing.

Martijn

[emmap]

Outbound traffic from a gateway is basically always sourced from the interface IP that it exited on. So, it's not NAT'ing anything, it's the actual source IP of the packet, so a noNAT rule won't change anything. (unless you're seeing an actual NAT statement in the log card for this traffic, in which case I am confused). 

You can try an explicit NAT to set it back to the other interface IP, but I can't guarantee this would work reliably or at all. 

[an_technical]

Hi @emmap : The MPLS interface is set to internal at the moment. I am not able to understand why its natting it to the MPLS Interface IP. The setting hide internal networks behind the gateway's external ip is also not selected. We don't see nat in logs, but NAT is happening when we see is tcpdump.

How to do explicit NAT? I was checking if this is expected behaviour?

[emmap]

As @Martijn says it sounds like you are describing normal outbound packet behaviour. If the packet is leaving a gateway, it will use the IP address of the interface it left on (or the VIP of that interface if it's a cluster). There is no NATing occuring in your logs because the gateway is not NAT'ing anything, it's just sending a packet from an interface and using the IP of that interface as its source IP.

[Vincent_Bacher]

I have now reread the original post and lo and behold, your post has opened my eyes. I first read that it uses VIP, but it actually uses its own MPLS IP. So you are absolutely right, it works as designed.

[Vincent_Bacher]

As mates already stated, this should not happen. Was the behavior from beginning? Would suprise because this should not be standard behavior.
Anyway, i remember the sk https://support.checkpoint.com/results/sk/sk34180 which you might check.
If this has been modified you should check why this has been done.
long ago there was an option to select which protocols have been hidden behind vip but i forgot all about it.

[an_technical]

Hi @Vincent_Bacher : This behaviour is from begining and we are seeing this on all locations linked with MPLS connection to DC MGMT SRVR.

I also checked sk34180, and the configuration has not changed.

[Vincent_Bacher]

Strange, in this case I would log a sr at UC and ask tac.