DHCP Relay gets dropped through IPSec Tunnel

  • Hi Guys,

    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".

    Any thoughts???

    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.

    Best regards!

  • 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?

Log in to reply