Google VPN / VTI / everything works except ping from pfsense

cukal

I've setup an IPSec / VTI tunnel (2.4.5p1) to Google VPN and everything pretty much works (from lan to VPC) except for pinging a VM instance from pfsense.

Packet capture on pfsense:

00:10:54.219472 IP 169.254.40.1 > 10.132.0.2: ICMP echo request, id 59191, seq 0, length 64
00:10:55.219551 IP 169.254.40.1 > 10.132.0.2: ICMP echo request, id 59191, seq 1, length 64
00:10:56.221004 IP 169.254.40.1 > 10.132.0.2: ICMP echo request, id 59191, seq 2, length 64

tcpdump on the gc vm instance shows it does receive the requests and sends replies:

22:12:23.976986 IP 169.254.40.1 > 10.132.0.2: ICMP echo request, id 42660, seq 0, length 64
22:12:23.977267 IP 10.132.0.2 > 169.254.40.1: ICMP echo reply, id 42660, seq 0, length 64

But I don't receive the reply on pfsense, nor do I see it in the packet capture on pfsense.

I tried adding 169.254.40.1/32 as a route in the VPC but that didn't change anything.

Anyone any ideas?

Rico

169.254.0.0/16 is Link Local and AFAIK not routed by FreeBSD/pfSense.

-Rico

cukal

Tried resolving it with TAC but to no avail. Enabling APIPA didn't change anything. I'm not sure where the problem lies but I'm guessing the VPC is refusing to route 169.254.x.x as it's strictly speaking not within a defined VPC route. I've noticed in another issue that any packet with an RFC1918 target ip without a defined route and an available target instance or VPN route with that RFC1918 range gets blocked straight after egress from the vm instance.

Traffic from pfsense LAN networks works flawless but the reason I need a ping from pfsense is because I'm running a blackbox_exporter on pfsense to monitor the IPSec tunnel by pinging the remote GC vm instance.

I worked around it by adding a VPC route to pfsense LAN1/32 address with the tunnel as gateway allowing only ICMP and added a blackbox_exporter icmp config with the LAN1/32 ip as source_address. That way the ping requests arrives at the GC instance with LAN1/32 source ip and the reply gets accepted because there's a defined VPC route and gets send through the tunnel.

Gr.