- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Cant reach bgp networks from Cluster XL members
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cant reach bgp networks from Cluster XL members
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ty for your help, was very useful.
after the change, i will be back!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!