Cant reach bgp networks from Cluster XL members

[Roh_oh]

Hi Guys, hope one of you can give an idea about this behavior

We have a cluster XL with BGP with several GW and we connect that BGP via Ipsec routed base tunnel.

Every host behind the firewalls is ABLE to ping the remote networks learning by BGP but i am not able to do it from the active member firewall.

I also tried to ping by source but nothing.

fw ctl zdebug + drop is showing nothing.

Topology is:

Cluster XL interfaces:

bond1.1 with public IP.

bond1.2 transit private IP 10.100.200.247 (physical 248 and 249)

bond1.3 private IP 10.100.1.250 (physical 248 and 249)

the Bond is connected to a switch that has 3 Interface Vlan

Int clan 1.1 : External public IP

int vlan 1.2: 10.10.10.1 (default gateway for local host)

int vlan 1.3: local network.

Connecto from the local network and trace to the remote host:

traceroute 172.22.241.47

traceroute to 172.22.241.47 (172.22.241.47), 64 hops max, 52 byte packets

1  192.168.10.1 (192.168.10.1)  2.481 ms  2.106 ms  2.197 ms

2  10.100.200.247 (10.100.200.247)  3.183 ms *  3.225 ms

3  10.11.1.65 (10.11.1.65)  32.279 ms  35.524 ms  41.145 ms IPSEC TUNNEL BGP 

4  * * *

^C

ping 172.22.241.47

PING 172.22.241.47 (172.22.241.47): 56 data bytes

64 bytes from 172.22.241.47: icmp_seq=0 ttl=123 time=209.151 ms

64 bytes from 172.22.241.47: icmp_seq=1 ttl=123 time=40.271 ms

64 bytes from 172.22.241.47: icmp_seq=2 ttl=123 time=39.915 ms

64 bytes from 172.22.241.47: icmp_seq=3 ttl=123 time=48.013 ms

/////////////////

From Firewall

CP-2> traceroute 172.22.241.47

traceroute to 172.22.241.47 (172.22.241.47), 30 hops max, 40 byte packets

1  10.11.1.65 (10.11.1.65)  28.403 ms  28.247 ms  28.286 ms

2  * * *

3  * * *

4  * * *

5  * * *

6  * * *

7  *^C

CP-2> ping 172.22.241.47

PING 172.22.241.47 (172.22.241.47) 56(84) bytes of data.

^C

--- 172.22.241.47 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 2001ms

CP-2> ping -s 10.100.1.249 172.22.241.47

PING 172.22.241.47 (172.22.241.47) 10(38) bytes of data.

^C

--- 172.22.241.47 ping statistics ---

34 packets transmitted, 0 received, 100% packet loss, time 32998ms

show route destination 172.22.241.47

Codes: C - Connected, S - Static, R - RIP, B - BGP (D - Default),

       O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),

       A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,

       NP - NAT Pool, U - Unreachable, i - Inactive

B               172.22.240.0/20     via 10.11.1.65, vpnt40, cost None, age 8432

/////////

From remote host

ping 10.100.1.250

Pinging 10.100.1.250 with 32 bytes of data:
Reply from 10.100.1.250: bytes=32 time=36ms TTL=61
Reply from 10.100.1.250: bytes=32 time=32ms TTL=61

Ping statistics for 10.100.1.250:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 32ms, Maximum = 36ms, Average = 34ms

Also when I tcpdump the outgoing ping from the firewall I don't see anything, but could be a common behavior right?

Any help will be appreciated! 

Thx!

[PhoneBoy]

What is at the Remote End of the tunnel in this case?
On Check Point, the gateway itself is automatically included in the Encryption Domain.
If the remote end is not configured appropriately, then you will see the behavior you’re seeing since the remote end may not be expecting that traffic to be encrypted.

[Roh_oh]

@PhoneBoy What is at the Remote End of the tunnel in this case? is a remote Cisco Router and yes could be the reason for this behavior, but sadly is not on my mgmt, and that is why I'm looking for extra help.

Regarding "On Check Point, the gateway itself is automatically included in the Encryption Domain." That is something good to know, but I have an extra question about that.

Is possible that the "VPN sharing" option was config as "One VPN tunnel per Security Gateway pair".Could this be the reason for this behavior?  because the documentation says "One VPN tunnel is created between peer Security Gateways and shared by all hosts behind each peer Security Gateway."

[PhoneBoy]

I don't believe "one VPN tunnel per Security Gateway pair" is relevant in this case, especially since the issue is with traffic originating from the gateway itself.
Your options are:

• Have the remote end change the configuration so that the gateway's external IP is included in the encryption configuration (not just the subnets behind the gateway).
• Exclude the gateway IP from the Encryption Domain on your end.

In R81.20 (and possibly other versions) there's a simple checkbox to exclude it:

If this option is not available on your version, you will need to apply the steps in Scenario 3 here: https://support.checkpoint.com/results/sk/sk108600

[Roh_oh]

Let me ask some questions about the exclusion 

this is my current config.

we are running a route-based IP sec tunnel and that is why we do it in this way. Maybe this is the reason?

every VPN community has an empty group like:

what is the main difference between these 2 ways of configs? 

TY!

[the_rock]

You can have empty group as enc domain, BUT, what really matters for VPN context is whats configured as enc domain per community, which is controlled by set option in your first screenshot.

Andy

[PhoneBoy]

It's not relevant to the issue at hand.

The original description you provided suggests traffic originating from your gateway to the remote gateway is getting encapsulated in IPsec but the remote end isn't expecting it.
This is why your pings/traceroutes to the external IP of the remote site fail.
You can fix it using one of the two methods I describe above.

[Roh_oh]

Ty for your help, was very useful.

after the change, i will be back!

[the_rock]

I agree with @PhoneBoy . Also, try below commands. Just as an example, lets say src ip is 1.1.1.1 and dst is 2.2.2.2 and port is 444

ip r g 2.2.2.2

fw monitor -F "1.1.1.1,0,2.2.2.2,444,0" -F "2.2.2.2,0,1,1,1,1,444,0"

Idea is this with -F flag "src ip, src port, dst ip, dst port, protocol"

Andy

[Roh_oh]

ip r g 172.22.241.47

172.22.241.47 via 10.11.1.65 dev vpnt40 src 10.11.1.66

    cache

66: local tunnel ip

65: remote

With Fw monitor I was not lucky, I didn't be able to capture any packet, pinging the remote host in another session.

Thx Guys!