Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
lullejd
Contributor

Incorrect NAT IP on Interface when failover

Hi all,

We have this weird situation. Our firewall has a BGP peering with a peer from which certain routes are being learned. The BGP PEER is 172.17.0.10 as per diagram below. One of the routes learned from this peer is 1.1.1.0/24.

 
 

2021-09-30 08_11_58-Window.png

 

BGP works fine and as per below screenshot, it can be seen that route towards 1.1.1.0/24 should pass through eth2.777.

2021-09-30 08_12_49-Window.png

So far so good. Traffic passes fine. Source 172.16.168.34 is able to talk to 1.1.1.0/24 through eth2.777. The source 172.16.168.34 is NATted behind the gateway ip address which is 172.17.0.1.

2021-09-30 08_13_23-Window.png

The issue arises when BGP peer is down. Obviously the learned routes will not be available so since 1.1.1.0/24 is a public IP address, traffic goes then through eth5 which is through the default route.

2021-09-30 08_13_57-Window.png

The only thing is that through fw monitor, we can see that traffic although is going out through the correct interface (eth5), it is still being NATted behind the IP address of interface eth2.777.

2021-09-30 08_15_52-Window.png

 

In this case originally I was pinging 1.1.1.1 and upon route failover, it stopped working since NATting is not being changed accordingly. However if I try to ping another IP address which was not in use before for example 1.1.1.2, NATting is performed correctly and hidden behind the public ip of eth5. This is causing severe outages on our environment because we expect that traffic is NATted correctly when route failover occurs. It seems that NAT problem occurs only on machines which already have a connection established. So somewhere in the NAT table the values are not being updated.

Effectively this is a lab environment I have created since originally this is a production critical system.

I have also tried to disable secureXL however to no avail. Our production firewalls are with R80.30 Jumbo Hotfix 217, however in the lab I managed even to replicate it on R81 with latest jumbo hotfix, so it seems something common on Checkpoint.

Has anyone encountered such behaviour and how did you overcome it? Basically traffic going out of the correct interface but NATting with the wrong IP address.

For traffic that is ICMP its solved with this command - fw_allow_simultaneous_ping 1 , however we have multiple tunnels which are being established behind our firewall using UDP/443, which when primary route (BGP) is down, they need to still be reachable via the default route.

Thanks in advance

Senior Information Security Engineer
0 Kudos
9 Replies
This widget could not be displayed.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 08:00 AM (CDT)

    South US: HTTPS Inspection Best Practices

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Tue 23 Apr 2024 @ 08:00 AM (CDT)

    South US: HTTPS Inspection Best Practices

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events