DHCP relay through GRE over IPsec

[tuukka.smolander]

Hi!

I have a data center with virtual desktops and other shared infrastructure serving remote sites, some of which are connected to the data center with GRE over IPsec.

IP address management including DHCP is centralized in my architecture, but I simply cannot figure out how to relay DHCP requests through GRE over IPsec to my DHCP server cluster. I am working with Cisco 800 series VPN peers, and the VPNs are terminated either on a 1841 or a Juniper SRX. Everything else is just fine and dandy, but DHCP is not forwarded across the GRE tunnel.

As a workaround I am forced to use local DHCP pools on the VPN peers, which is extra work from a management point of view, and also precludes static IP address assignment where a local DHCP pool is in a VRF. My LAN devices are mostly thin clients, so I don't care if DHCP stops working when the WAN link fails. As such local pools have no upsides, they are only a tremendous hassle.

My config is very basic, public WAN in global routing table and WAN + GRE tunnel in a VRF. NAT is not used. Here are the DHCP-related configs I have tried:

• ip helper-address on the LAN gateway, both with and without ip forward-protocol udp bootpc
• ip dhcp pool with relay options configured

In every case, I can see the UDP broadcasts hit the LAN gateway, but relayed packets never arrive at the other GRE tunnel endpoint let alone the DHCP server. Can anyone help?

[Peter Paluch]

Hello Tuukka,

Sorry for replying lately.

Using a DHCP Relay over a GRE/IPsec tunnel should not be different in any way from any other DHCP Relay deployment. You seem to have correctly applied the ip helper-address on your LAN interface. You should not need to redefine the ip forward-protocol, nor create DHCP pools with the relay option.

Are you using the crypto profiles together with the tunnel protection ipsec command, or are you using crypto maps applied on the outgoing interface?

A few things to consider:

• The relayed DHCP client message captured on the LAN interface will be sent towards the IP address defined in the ip helper-address command. This destination must be reachable according to your routing table, and must be routed towards the GRE tunnel.
• Also, this relayed message will be sourced (the source IP address will be taken) from the LAN interface. The DHCP server will use this information to choose an appropriate pool to serve IP addresses from, and also, it will send its reply back to this address. That means the entire infrastructure between the LAN and the DHCP server must allow for successful bidirectional IP communication going over the GRE/IPsec tunnel.

Can you confirm that the relayed DHCP packets are not reaching the DHCP server? Also, would it be possible to post here the configuration of the router on the remote site where the DHCP clients are located?

Thank you!

Best regards,

Peter

[tuukka.smolander]

Hi Peter, thanks for the reply!

I am indeed using crypto profiles with tunnel protection ipsec on the tunnel interface. The DHCP server is reachable, a pool for the LAN exists, but the DHCP server logs do not contain any messages from the LAN.

The remote router is a Cisco 887VDSL2 with C880DATA-UNIVERSALK9-M, Version 15.0(1)M4. Here's the relevant config with just the ip helper-address set:

ip vrf PRIVATE rd 1:1 crypto isakmp policy 1 encr aes 256 authentication pre-share group 5 crypto isakmp key XXX address XXX crypto isakmp invalid-spi-recovery crypto isakmp keepalive 10 ! ! crypto ipsec transform-set ESP_AES_256 esp-aes 256 esp-sha-hmac ! crypto ipsec profile CIPHER-AES-256 set transform-set ESP_AES_256 interface Tunnel0 ip vrf forwarding PRIVATE ip address 172.20.0.58 255.255.255.252 tunnel source Vlan100 tunnel mode ipsec ipv4 tunnel destination XXX tunnel protection ipsec profile CIPHER-AES-256 interface Vlan1 ip vrf forwarding PRIVATE ip address 10.212.11.1 255.255.255.128 ip helper-address 10.211.0.86 ip tcp adjust-mss 1350 interface Vlan100 ip address XXX ip virtual-reassembly ip route 0.0.0.0 0.0.0.0 XXX ip route vrf PRIVATE 0.0.0.0 0.0.0.0 172.20.0.57

Unicast ICMP and TCP from the LAN to the DHCP server works:

XXX#sh ip ro vrf PRIVATE Routing Table: PRIVATE Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2        i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2        ia - IS-IS inter area, * - candidate default, U - per-user static route        o - ODR, P - periodic downloaded static route, + - replicated route Gateway of last resort is 172.20.0.57 to network 0.0.0.0 S*    0.0.0.0/0 [1/0] via 172.20.0.57       10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C        10.212.11.0/25 is directly connected, Vlan1 L        10.212.11.1/32 is directly connected, Vlan1       172.20.0.0/16 is variably subnetted, 2 subnets, 2 masks C        172.20.0.56/30 is directly connected, Tunnel0 L        172.20.0.58/32 is directly connected, Tunnel0 XXX#ping vrf PRIVATE 10.211.0.86 so vl1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.211.0.86, timeout is 2 seconds: Packet sent with a source address of 10.212.11.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms XXX#telnet 10.211.0.86 domain /vrf PRIVATE /source vl1

Trying 10.211.0.86, 53 ... Open [Connection to 10.211.0.86 closed by foreign host]

XXX#

[Peter Paluch · Accepted solution]

Hello Tuukka,

Thank you very much for the info!

Let's make an experiment to see what is really going on. Try to run the following debugs:

debug ip dhcp server packet

debug ip dhcp server events

debug ip packet 199

where the ACL 199 is as follows:

access-list 199 permit udp any eq bootpc any eq bootps

access-list 199 permit udp any eq bootps any eq bootpc

This should help us to see whether the DHCP Relay Agent actually kicks in, how does it repackage the DHCP message, and most importantly, where does it send it. The one thing I am wondering is whether the IOS resolves your IP helper address in the VRF PRIVATE namespace or in the global routing table. I would be then very interested in seeing the debug outputs.

By the way, try entering the following two commands into your configuration, just to be on the safe side:

service dhcp

ip dhcp use vrf connected

Best regards,

Peter

[tuukka.smolander]

Hi Peter,

thank you for your help with this issue. This is a production circuit, but I finally managed to get a window for running the tests. Lo and behold, it started working!

The DNS server configuration or the router running-config have not been changed at all, the only difference is that I applied the commands "service dhcp" and "ip dhcp use vrf connected" to the router. I must admit that I don't understand what happened before, but the most important thing is that now we have a functioning setup.

Thanks again!