Help getting dhcp-relay working

My current and working setup is as followings.

vyos-rolling running on esxi 6.7u3

native lan on eth1 - 192.168.68.0/24
dhcp server - windows 2019 @ 192.168.68.22

eth2 is a vlan interface .100 using a port group on esxi - 192.168.100.0/24
dhcp served by the vyos router

eth3 is a vlan interface .110 using a port group on esxi - 192.168.110.0/24
dhcp served by the vyos router

vswitch has all security disabled, allows promiscuous mode etc.

As it stands all is working fine. native and vlan traffic flows, dhcp leases are working etc.

I am wanting to use the windows 2019 server for all dhcp leases and scopes. Configured and activated the .100 and .110 scopes on the Windows server, deleted the dhcp-server definitions on the router and replaced with the following

    dhcp-relay {
    interface eth2
    interface eth3
    relay-options {
        relay-agents-packets discard
    }
    server 192.168.68.22
}

However, that results in breaking the eth2 and eth3 networks as nothing is getting a dhcp assigned address. I have no firewall rules active between the zones while I am getting this up and running, i.e. all interfaces can freely communicate, with the dhcp-server scopes running on the router once devices get an address I can reach all IPs on eth1, including that of the Windows 2019 dhcp server.

Any help on solving this issue would be appreciated.

Full config attached.

config.txt (37.9 KB)

Hello,
Try adding eth1 to the dhcp-relay interfaces.

I was able to mimic your setup in GNS3 but using FreeBSD 12.1 with isc-dhcpd instead of Windows Server and saw the same behavior. The server was seeing the DHCP discover requests but the Offer was not being routed back to the clients and VyOS was responding with a “Destination unreachable”.

Searching Phabricator lead me to T1276 which mentions isc-dhcp-relay expects to be listening on both the send and receive interfaces.

/usr/local/etc/dhcpd.conf-

default-lease-time 600;
max-lease-time 86400;
log-facility local7;

subnet 192.168.68.0 netmask 255.255.255.0 {
 range 192.168.68.100 192.168.68.200;
 option routers 192.168.68.1;
 option broadcast-address 192.168.68.255;
 option domain-name-servers 192.168.68.1;
 default-lease-time 86400;
 max-lease-time 86400;
}

subnet 192.168.100.0 netmask 255.255.255.0 {
 range 192.168.100.100 192.168.100.200;
 option routers 192.168.100.1;
 option broadcast-address 192.168.100.255;
 option domain-name-servers 192.168.100.1;
 default-lease-time 86400;
 max-lease-time 86400;
}

subnet 192.168.110.0 netmask 255.255.255.0 {
 range 192.168.110.100 192.168.110.200;
 option routers 192.168.110.1;
 option broadcast-address 192.168.110.255;
 option domain-name-servers 192.168.110.1;
 default-lease-time 86400;
 max-lease-time 86400;
}

VyOS config-

interfaces {
    ethernet eth0 {
        address dhcp
    }
    ethernet eth1 {
        address 192.168.100.1/24
    }
    ethernet eth2 {
        address 192.168.110.1/24
    }
    ethernet eth3 {
        address 192.168.68.1/24
    }
}
nat {
    source {
        rule 10 {
            outbound-interface eth0
            translation {
                address masquerade
            }
        }
    }
}
protocols {
    static {
        route 0.0.0.0/0 {
          dhcp-interface eth0
        }
    }
}
service {
    dhcp-relay {
        interface eth2
        interface eth1
        interface eth3
        relay-options {
            relay-agent-packets forward
        }
        server 192.168.68.22
    }
}
1 Like

Legend!

As soon as I added the LAN interface it worked a treat. Many thanks for taking the time to help me out here.

I think I should get to learn how to use GSN3…

You’re welcome! I’m glad I could help and that it’s working for you.

GNS3/EVE-NG can be pretty handy to help troubleshoot or lab up a scenario and work through possible solutions; I suggest checking them out if you’re interested in making some virtual test environments.

I will do just that.

I want to get vrrp running and no idea where to start. That should give me a sandbox I assume.

Yes, the GNS3 environment can be completely sandboxed, NAT’ed to your real network (NAT object), or piggy back off a real interface and participate in routing or switching (“cloud” object). I have it running on some older server hardware and use the GUI client on my workstation; it works quite well. I haven’t used EVE-NG so I can’t comment on that.

One thing that caught me when setting up VRRP is that the vrid has to be the same on all members participating in that particular VRRP group. And you need to create a sync group if you want to use it with conntrack-sync.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.