3

I have the following setup on a remote office:

--- vlan interface --- Remote Router --tun0--> Main office Firewall --> Active Directory DHCP

I'm using dhcp3-relay to forward dhcp requests(broadcasts) to my main AD server(unicast). Problem is: dhcp request arrives at the Remote Router vlan interface(broadcast), is correctly forwarded through routing to our AD server, an answer is given but when receiving the packet, it isn't internally forwarded from tun0 to the vlanXXX interface of the Remote Router where the request originaly came from. Here it is the tcpdump output from the Remote Router.

tun0 interface:

tcpdump -i tun0 -nevvv udp port 67 or 68

13:23:45.049995 Out ethertype IPv4 (0x0800), length 592: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 576) IP.VPN.REMOTE.OFFICE.67 > IP.OF.AD.SERVER.67: BOOTP/DHCP, Request from MAC:ADDR:OF:THE:REMOTE:CLIENT, length 548, hops 1, xid 0x2c896edc, secs 11527, Flags [none] (0x0000)
          Gateway-IP IP.OF.NET.GATEWAY
          Client-Ethernet-Address MAC:ADDR:OF:THE:REMOTE:CLIENT [|bootp]

13:23:45.145014  In ethertype IPv4 (0x0800), length 350: (tos 0x0, ttl 125, id 24829, offset 0, flags [none], proto UDP (17), length 334) IP.OF.AD.SERVER.67 > IP.OF.NET.GATEWAY.67: BOOTP/DHCP, Reply, length 306, xid 0x2c896edc, Flags [none] (0x0000)
          Your-IP NEW.LEASE.FROM.AD
          Server-IP IP.OF.AD.SERVER
          Gateway-IP IP.OF.NET.GATEWAY
          Client-Ethernet-Address MAC:ADDR:OF:THE:REMOTE:CLIENT [|bootp]

Here you can see that the packet is correctly forwarded by the dhcrelay software to our main office, and AD gives a new lease to the host. We already have this solution working on other links that are not openvpn based(mpls) to distribute IPs to remote offices.

vlanXXX interface:

tcpdump -i vlanXXX -nevvv udp port 67 or 68

13:21:45.022067 MAC:ADDR:OF:THE:REMOTE:CLIENT > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 64, id 147, offset 0, flags [none], proto UDP (17), length 576) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from MAC:ADDR:OF:THE:REMOTE:CLIENT, length 548, xid 0x496364c3, secs 11407, Flags [none] (0x0000)
          Client-Ethernet-Address MAC:ADDR:OF:THE:REMOTE:CLIENT [|bootp]

We can only see the broadcast request comming from the host, but not the answer that arrived at tun0 and should be routed to vlanXXX.

Also, Remote Router is pretty permissive with this protocol:

iptables -A INPUT  -p udp --sport 67:68 --dport 67 -j ACCEPT
iptables -A OUTPUT -p udp --sport 67 --dport 67:68 -j ACCEPT
iptables -A FORWARD -p udp --sport 67:68 --dport 67 -j ACCEPT
iptables -A FORWARD -p udp --sport 67 --dport 67:68 -j ACCEPT

dhcp3-relay process info:

hafw:~# ps fax | grep dhc
 5714 pts/0    D+     0:00                      \_ grep dhc
 5087 ?        Ss     0:04 /usr/sbin/dhcrelay3 -i vlanxxx IP.OF.AD.SERVER

default configuration(/etc/default/dhcp3-relay):

# Defaults for dhcp3-relay initscript
# sourced by /etc/init.d/dhcp3-relay
# installed at /etc/default/dhcp3-relay by the maintainer scripts

#
# This is a POSIX shell fragment
#

# What servers should the DHCP relay forward requests to?
SERVERS="IP.OF.AD.SERVER"

# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?
INTERFACES="vlanXXX"

# Additional options that are passed to the DHCP relay daemon?
OPTIONS=""

Software version:

hafw:~# dpkg -l | grep dhcp3-relay
ii  dhcp3-relay                            3.1.1-6+lenny6           DHCP relay daemon

What i have already tried to do on relay configuration and didn't change the behavior:

  • Add -a option to append agent info
  • Add -c 20 and increase the number of hops from the default(10) to 20. Anyway, there are only 8 hops to reach AD.
  • Add tun0 and the internet vlan interface vlanYYY that is facing internet.
  • Let INTERFACES=empty so, there will not be a -i option.

Am I missing something?

  • You've used iptables -A. This Appends to whatever rules are present. (Contrast with -I to Insert at the beginning of a rule set.). If one of those is a REJECT/DROP you'll never reach your ACCEPT rules. Check with iptables -nvL – roaima Apr 20 '18 at 17:56
  • 1
    Done that with -I also. No efect whatsoever. Also, those rules are at the top of my script, and every rule after, is also using -A so, not a big deal here.. – user34720 Apr 21 '18 at 16:01
  • iptables operates at the IP level (Level 3). You'll need ebtables, which operates at Ethernet level (Level 2). – Ralph Rönnquist Apr 21 '18 at 23:00
  • @RalphRōnnquist the OP is routing, not bridging. – roaima Apr 22 '18 at 5:47
  • @RalphRönnquist as said by roaima(and by me at the question), dhcprelay does not operates at L2, but L3. It gets the broadcasts and it routes to the forwarder dhcp server. @roaima. It's the same software. The package is called dhcp3-relay on debian, but the binary is dhcrelay(isc). I have also tried the dhcp-helper software that conflicts with all ISC stuff, same issue. Pretty much the configs(not at work now) are to listen at the vlan interface and the IP of the AD. I have also tried to put it to listed at the TUN interface and the internet facing vlan interface without any progress. – user34720 Apr 23 '18 at 0:53
1

This looks like a design fault within the dhcrelay utility itself. It can only listen on broadcast interfaces, and OpenVPN is a point-to-point interface. The -i flag will not change this (it will only reduce the number of selected interfaces from the set of broadcast interfaces).

The work-around appears to be to run dhcrelay on a device within your remote LAN, and not on the gateway itself. The relayed unicast traffic will then be passed through the OpenVPN tunnel to the DHCP server and back again.

If you need a tiny/cheap server for this sort of task I can recommend the Raspberry Pi running Raspbian (Debian in disguise). I run DNS on a pair of them in each of our remote offices.

References

  • I don't know how this workaround can be of use, since the other host i have at the my side is also a Linux host with OpenVPN server, and i will still need a way to turn broadcasts into unicast, and that is a role accomplished by dhcrelay... And note that, im using only one vlan on this issue, but on other offices that have some circuit with the main office(mpls) there are several vlans being relayed. I started as a test on OpenVPN and would expand if it worked. – user34720 Apr 24 '18 at 18:20
  • @nwildner you run dhcrelay on a system on the remote LAN. Not on the gateway. That way it will have suitable broadcast network interfaces. If your remaining device also runs OpenVPN then expect dhcrelay not to work correctly with that device's tun interfaces (but my understanding is that it will work with the eth interfaces). – roaima Apr 27 '18 at 11:08
  • Problem here is to forward the broadcasts that comes from the vlan interface to tun0. Using iptables(ebtables) it will require me to change from tun to tap (remote offices AND main office) to achieve brodcasts forward(en.wikipedia.org/wiki/TUN/TAP) to reach the remote dhcrelay and that is not going to happen since we have lots of routes to each office(more than 10 actually). And also, i have other vlans on all remote firewalls and it will make the administration lot hard. Seems that i'm on a dead end... – user34720 May 4 '18 at 11:31
  • What really bugs me is that, 2 different dhcp relay software have the same problem(isc-dhcp-relay and dhcp-helper) so, doesn't seems to be an issue with relay software. – user34720 May 4 '18 at 11:33
  • @nwildner have you tried my suggestion? I don't know how else to describe the solution; this is my third attempt. Run the relay on a different device on the remote LAN. It will pick up the "Can I have an IP address please" broadcasts and unicast them at your true DHCP server. The results will come back to the originating device via your existing routing tables. Job done. – roaima May 4 '18 at 12:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy