VSX bootp relay originating from wrong IP

[stallwoodj]

Hi,

We have VSX running on R81.20 JHF76, with one virtual system (id 5) running just FW1+VPN blades. It has one LAN interface, an external and a numbered VTI with universal tunnel. The default route is up the tunnel.

The client LAN is set to do DHCP relay to a remote server:

set bootp interface bond101.XXX1 on
set bootp interface bond101.XXX1 relay-to XXX.XXX.XXX.231 on
set bootp interface bond101.XXX1 primary 192.168.50.254

However, the DHCP relay is originating from the wrong IP - it's from the vsx private subnet, and it's then automatically NATted it behind the outgoing interface (VTI).

Has anyone else had this problem?

Thanks

Jamie

[emmap]

If you do a 'show route destination [ip of your relay-to server]' from clish or 'ip route get [ip of your relay-to server]' from expert in the VS5 context, does it have a route out of the correct interface?

[stallwoodj]

Hi Emma,

Yes, it's following the default route up the tunnel

[Expert@FW-VSX-PRI:5]# ip route get XXX.XXX.XXX.231
XXX.XXX.XXX.231 via 192.0.2.81 dev vpnt509 src 172.31.248.33
cache


[Expert@FW-VSX-PRI:5]# ip route
default via 192.0.2.81 dev vpnt509 proto 7
172.31.248.0/28 dev wrp320 proto kernel scope link src 172.31.248.1
172.31.248.16/28 dev bond101.3xx1 proto kernel scope link src 172.31.248.17
PUBLICIP.0/27 dev wrp320 proto 7 scope link
192.0.2.81 dev vpnt509 proto 7 scope link
192.168.50.0/24 dev bond101.3xx1 proto 7 scope link
VPNPEER via PUBLICIP.30 dev wrp320 proto 7

[emmap]

It looks like it's going to route the DHCP requests up the VPN tunnel to the relay, is that intended? If not you might should add a static route to the correct next hop for it.

The Primary IP in the bootp config isn't there to set the source IP on the packets. From the admin guide: it's the IPv4 address to use as the BOOTP/DHCP router address. If you enter an IPv4 address, all BOOTP/DHCP requests received on the interface are stamped with this IPv4 address. This can be useful on interfaces with multiple IPv4 addresses (aliases).

Hence the outgoing packets are still going to use the source IP on the interface they are routed out of.

[stallwoodj]

Thanks, is there a way we can "persuade" the NAT to use the LAN-side vip 192.168.50.254 as its hide NAT, not the outgoing tunnel interface? We only have a number on the VTI because it's VSX, and the other end doesn't by default know how to route back to the tunnel local interface.

[emmap]

The cluster hide NAT isn't something that can be directly affected in that way. You can try adding a hideNAT rule in the policy but outbound hide NAT for packets originating from the gateway doesn't generally work. Would it be possible to NAT it at the other end of the VPN tunnel?

[stallwoodj]

Yeah, we ended up doing that to change the private tunnel IP into something that the 3rd party could route.