|
We have an interesting issue here. My client has a
firewall with two external interfaces going to 2 external routers. One interface
is going to a primary T-1, the second is going to a secondary T-1 provider.
Right now the failover is manual in nature and a pain in the ass, but that is a
seperate issue. They have a tunnel going to another remote location which
works fine when they cut over. That remote location has a tunnel with colocation
provider which is working. They also have a VPN tunnel frmo new york
to colocation provider. When we were on the primary T-1 everything was
smooth, once we cut-over (UUnet went down) it stopped working. So the primary
external interface is now set to the other provider. Here is whats
happening:
The VPN tunnel works fine to the remote location
and back
Remote location to Colo provider works fine.
The VPN tunnel to
colo provider only works when the UUnet line is up and running. They insured me
that they have changed the object to point to our cutover ip address of the
firewall in NY, but this is what I am seeing...
BTW The firewalls are running IPSO 3.3
Checkpoint 4.1 SP2
First let?s look at the output on the remote
location firewall. As you can see the packets going to colo provider are
destined for the .23 address. The packets that are coming back are from .24
address. 23(VRRP) 24(Physical) (colo provider's firewalls)
remote_firewall[admin]# tcpdump -i eth-s1p1c0|grep
"64.x.x.23"
tcpdump: listening on eth-s1p1c0
15:01:23.495922 216.x.x.70
> 64.x.x.23: ip-proto-50 532
15:01:23.759654 216.x.x.70 > 64.x.x.23:
ip-proto-50 300
remote_firewall[admin]# tcpdump -i eth-s1p1c0|grep
"64.x.x.24"
tcpdump: listening on eth-s1p1c0
15:02:24.813542 64.x.x.24
> 216.x.x.70: ip-proto-50 140
15:02:37.970975 64.x.x.24 > 216.x.x.70:
ip-proto-50 140
Now let?s go over to NY(the firewall with a
problem):
The packets are now going to the SS VRRP address but there is
nothing coming back on .23 nor .24.
ny_firewall[admin]# tcpdump -i
eth-s1p2c0|grep "64.x.x.23"
tcpdump: listening on eth-s1p2c0
15:17:25.309681 O 206.x.x.204 > 64.x.x.23:
ip-proto-50 76
15:17:25.918394 O 206.x.x.204 > 64.x.x.23:
ip-proto-50 244
Now let?s look at the UUnet interface of the
NY firewall.
ny_firewall[admin]# tcpdump -i eth-s1p1c0|grep
"64.x.x.*"
tcpdump: listening on eth-s1p1c0
15:24:54.612874 I 64.x.x.24 > 63.x.x.2:
ip-proto-50 180
15:24:54.637762 I 64.x.x.24 > 63.x.x.2:
ip-proto-50 180
this solves our dilemma to a certain extent of how
are we communication with colo facility. As you can see the incoming packets are
coming in on the UUnet interface. The outgoing packets are leaving and following
our default gateway out through Intellispace. We now have asynchrounous routing
? which is fine.
It seems like the NY firewall is trying to negotiate with the VRRP
address at colo:
13:56:06.130082 O 206.x.x.204.500 > 64.x.x.23.500: udp
52
13:56:06.152651 O 206.x.x.204.500 > 64.x.x.23.500: udp
48
13:56:06.240097 O 206.x.x.204.500 > 64.x.x.23.500: udp 52
but no resposne from colo facility.
any time the UUnet circuit goes back up we see:
13:56:06.263279 I
64.x.x.24.500 > 63.x.x.2.500: udp 52
13:56:06.390659 I 64.x.x.24 >
63.x.x.2: ip-proto-50 84
13:56:06.428847 I 64.x.x.24 > 63.x.x.2:
ip-proto-50 84
Euge
| 
