0

I have a machine (lets call it device) that has an ipsec connection (VPN) to another machine (call it gateway). The device is tunnels to the gw through a virtual interface vti0 and everything works correctly for the most part. On the side of the gw I have a dhcp server which I have configured to assign an ip (in the net 11.2.0.0/16) to one of the virtual machines hosted on the device. The particular virtual machine is accessed through the mgmt0 interface on the device.

Device's vti0 (172.13.14.2) === tunnel === GW (192.168.122.2)

 vti0 ip is 172.13.14.2 
 mgmt0 ip is 11.2.0.1
 virtual machine MAC address is fa:16:3e:4f:e6:64

 DHCP Server ip 192.168.122.10
 GW ip 192.168.122.2

DHCP Server configuration:

subnet 11.2.0.0 netmask 255.255.0.0 {
range 11.2.0.2 11.2.255.254;
option routers 11.2.0.1;
}


subnet 192.168.122.0 netmask 255.255.255.0 {
        option routers 192.168.122.2;
        option subnet-mask 255.255.255.0;
        range  192.168.122.11 192.168.122.255;
}


host mgmt-node {
         hardware ethernet fa:16:3e:4f:e6:64;
         fixed-address 11.2.0.2;
 }

So, I have set up a DHCP relay on the device that sends the DHCP requests to the server, but doesn't send a response back.

DHCP relay configuration:

# What servers should the DHCP relay forward requests to?
SERVERS="dhcp-server"
# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?
INTERFACES="mgmt0 vti0"
# Additional options that are passed to the DHCP relay daemon?
OPTIONS=""

The requests go like this.

DHCPDISCOVER
Virtual machine request > Device relay
Device relay > GW
GW > DHCP Server

DHCPOFFER
DHCP Server > GW
GW > Device relay --- Stops

DHCP Server log:

авг 08 10:07:40 dhcpserver-Standard-PC-i440FX-PIIX-1996 dhcpd[3328]: DHCPDISCOVER from fa:16:3e:4f:e6:64 via 11.2.0.1
авг 08 10:07:40 dhcpserver-Standard-PC-i440FX-PIIX-1996 dhcpd[3328]: DHCPOFFER on 11.2.0.2 to fa:16:3e:4f:e6:64 via 11.2.0.1

The last place I can see the packet is on the device's vti0 interface being received.

From the journalctl log I see that the DHCP relay says: Aug 08 07:28:39 ipsec-client-automation sh[19208]: Forwarded BOOTREQUEST for fa:16:3e:4f:e6:64 to 192.168.122.10 Aug 08 07:28:39 ipsec-client-automation sh[19208]: Attempt to decode hw header for Pure IP Aug 08 07:28:39 ipsec-client-automation dhcrelay[19208]: Attempt to decode hw header for Pure IP

I could not find any information on what does "Attempt to decode hw header for Pure IP" mean, but it stops after that and I can't find advanced debugging for the DHCP relay, any ideas ?.

If anyone could give any advice, I'd appreciate it.

Kostadin Krushkov
  • 105
  • 2
  • 8
  • Your network is allocated IP that is part of the routable Internet address space - if it's not yours you will be preventing any clients from accessing that part of the Internet ... – Rob Lambden Aug 08 '19 at 08:33
  • Also you wouldn't normally have your DHCP Relay configured to get servers from multiple networks (mgmt0 and vti0) – Rob Lambden Aug 08 '19 at 08:33
  • I understand the consequences, but I still want to do it this way, because it's only a test configuration. The goal is just to establish traffic after receiving IP from the DHCP server. – Kostadin Krushkov Aug 08 '19 at 08:36

1 Answers1

0

So the error was in the DHCP relay configuration It should be like this:

# What servers should the DHCP relay forward requests to?
SERVERS="192.168.122.10"

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

# Additional options that are passed to the DHCP relay daemon?
#OPTIONS="-U 172.13.14.2%vti0"
OPTIONS="-U vti0"

The only difference is that in the INTERFACES there should only be the origin of the requests and on the options specifying with -U

If anyone is interesting in why: The reason this is happening is that without the -U option the giaddrs, which is a part of the DHCP request doesn't get changed. The giaddrs is the address of the next relay server the packet is supposed to go to, so if it isn't set, then it doesn't route to it.

I had mistaken in the fact that it was reaching the relay it was only trying to route from the GW to it without knowing how to find it.

Kostadin Krushkov
  • 105
  • 2
  • 8