IPSec and DHCP Relay



  • Hello,

    I want to use a sense box as a DHCP relay for a remote site, sending the DHCP requests through an IPSec VPN. This meant I ran into this little problem: https://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?

    Now I realize it's hard to do much about FreeBSD shortcomings, I'm more curious about whether this has improved in FreeBSD 10 and thus pfSense 2.2? Or by all means, if someone has found a good workaround. I tried the one mentioned in the article I linked, unfortunately the ICMP redirect sets the next-hop to the remote host, so the actual client just starts spamming arp who-has on the local network for a while until it gives up. Needless to say this isn't terribly helpful.



  • Not a short coming, just a fact of how IPsec functions and how source IP selection functions. Services that can bind to a specific source IP can do without the static route noted there. Ones that can't will work fine with the static route.



  • @cmb:

    Not a short coming, just a fact of how IPsec functions and how source IP selection functions. Services that can bind to a specific source IP can do without the static route noted there. Ones that can't will work fine with the static route.

    Odd, the dhcrelay service won't send anything through the tunnel. It picks the requests up and forwards them out through it's default GW. Then again now that I think about it it binds to an interface but listens to *:67 . About the static route, as I mentioned when I tested that it did the icmp redirect with the destination server as the next-hop, so that pretty much severs the IPSec tunnel for the network that gets routed that way.



  • If the described route is there, it should go out the tunnel as that'll determine its source IP selection. I don't recall anything with DHCP relay that's any different.

    The ICMP redirect you're describing would not happen with the described route. It does cause an ICMP redirect to be sent, but it's one that tells the client "to reach the remote IPsec network, hit my LAN IP", which is what they're doing anyway so it effectively does nothing. You can disable the ICMP redirects under System>Advanced, Tuning, if you don't need or want them in general. But that description makes it sound like the route wasn't right to begin with.



  • @cmb:

    If the described route is there, it should go out the tunnel as that'll determine its source IP selection. I don't recall anything with DHCP relay that's any different.

    The ICMP redirect you're describing would not happen with the described route. It does cause an ICMP redirect to be sent, but it's one that tells the client "to reach the remote IPsec network, hit my LAN IP", which is what they're doing anyway so it effectively does nothing. You can disable the ICMP redirects under System>Advanced, Tuning, if you don't need or want them in general. But that description makes it sound like the route wasn't right to begin with.

    Yeah, it did seem weird to me, so I checked it several times, and had a colleague check it for me as well just in case someone spiked something I drank, but the route was fine and that's the redirect the host got. In either case, installing the FreeBSD package mentioned in this post it worked without the route. The only difference I see between the two of them network wise is that the "unofficial" relay binds to a specific address as well as the interface, while the included daemon binds to * on the selected interface.


Log in to reply