VRRP Anti-spoofing and routing issue R62

[ChrisA]

We're running R62 on two clustered Nokias running VRRP. Active/Passive.
We have HP OpenView off one interface, and it monitors all the interfaces of both Nokias using pings to the interfaces' real (not virtual) ip addresses. This works fine when OpenView pings the interfaces on the primary Nokia, but when OpenView pings the interfaces on the secondary Nokia, the pings are routed through the primary and then over to the secondary, causing spoofing errors.

OpenView IP: 172.1.1.5/24
Nokia interface eth-s1p4, virt IP 172.1.1.1 (255.255.255.0)
- primary IP: 172.1.1.2
- secondary IP: 172.1.1.3

If OpenView tries to ping, say, interface eth-s2p3's real IP on the secondary.
Nokia interface eth-s2p3, virt IP is 10.1.1.1 (255.255.255.0)
- primary IP: 10.1.1.2
- secondary IP: 10.1.1.3

OpenView's routing table says the default route is 172.1.1.1, the Nokias' Virt IP closest to the device. The packet is routed to the primary, 172.1.1.2, which then routes the packet out of it's eth-s2p3 and into the secondary's eth-s2p3. Voila! We have a spoofing error: a packet that should come from eth-s1p4 is coming into the secondary Nokia's interface eth-s2p3!

Any ideas how to resolve this? Thank you!

[melipla]

If the openview server has an interface on 172.1.1.0/24 network, then you should be able to ping 172.1.1.3 without routing through the default gateway [because its directly connected]. If that is not the case then I suggest modifying your routing to correct this behaviour.

Alternatively you can hide-NAT 172.1.1.5 on the primary gateway to 10.1.1.5 and you should avoid any AntiSpoofing. ;)

[ChrisA]

The problem is when OpenView is trying to ping the ip address of a different interface than the one it's directly connected to. So if OpenView is connected to interface eth-s1p4, it is trying to ping the ip address of interface eth-s2p3 on the secondary nokia. That's where we run into problems.

[melipla]

Originally Posted by ChrisA

The problem is when OpenView is trying to ping the ip address of a different interface than the one it's directly connected to.

On the Openview system add a route:

route add -host 10.1.1.3 gw 172.1.1.3

[ChrisA]

Thank you. This worked. I had hoped that something in vrrp or elsewhere in the Nokias or in CheckPoint would "know" the interface IPs and could be configured to route directly to the secondary enforcement point if the destination was an interface on that enforcement point. That way, we wouldn't need to maintain usermods on OpenView and a couple of other monitoring systems that are trying to do the same thing. But again, defining static routes worked, so thanks for your help.