DHCP Relay gets dropped through IPSec Tunnel
this is a strange one:
I build a site-2-site VPN between 2 pfSense. pfSense_1 is an embedded system running dhcp relay for the clients. pfSense_2 is a virtuel maschine on ESXi in the datacenter with a DHCP Server behind it. I applied the static route to fix the known IPSec problem for DHCP, SNMP etc.
The problem now is: DHCP Requests get picked up by the DHCP Relay on pfSense_1, go through the tunnel to pfSense_2 with a destination to the DHCP server. The DHCP Server answers just fine and sends the DHCP Replay through the tunnel. The packets never arrive at the LAN Interface of pfSense_1. pfSense_1 logs: "dhcrelay: 17 bad IP checksums seen in 33 packets".
Also, the Pcket Capture WebGUI shows no packets at all, when I start the capture, the Logs says "kernel: vr0: promiscuous mode enabled" and drops right back to "kernel: vr0: promiscuous mode disabled". TCPdump on the console works flawless.
Had a closer look with wireshark on the capture file. The Datacenter pfSense_2 DHCP_Reply Packets look just fine. All fields are filled correctly and the IP Checksum is correct.
Ok, I swapped the pfSense_1 Appliance against another pfSense Installable with the same config. DHCP Relay IP Checksum error is gone. Bus till the DHCP Reply / Offer goes into the tunnel on pfsense_2 and never reaches the lan interface on pfSense_1. :(
I made the CoreSwitch on the Client-site be the DHCP Relay and everything workes flawless. This is acceptable for me, however, since I am going to rely on pfSense for a big data center / outsourcing project with several sites attached in the future, I would appreciate if someone can point me to what happened here. I am otherwise very happy with this product but this leaves a bad feeling without knowing what was going on. The articel (http://doc.pfsense.org/index.php/Why_can't_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F) explaines to me why a static route was needed to get the packets into the tunnel (even though I would be very appreciative for more details on this "issue", which seems to be by design), but I don't really get why the packets go into the tunnel and disappear on the way back.
Also, is there a way to debug traffic inside the ipsec-tunnel? Probably not using a packet sniffer since the traffic is encrypted, but is there some other, possible ipsec related, logfile etc. to tell me when and why packets get dropped and for what reason?