ASA issue: DHCP Server Does not Lease Ip to Remote VPN Site

[nwekechampion]

HI all,

I am in a bit of a pickle.

I have DHCP server that can

1. Lease IPs to devices in the same LAN

2. Can also be pinged (reachable) within the same LAN,

However the same dhcp server cannot do the above 2 things to remote site VPN.

My setup in summary:

1. DHCP running behind an ASA

2. Both sites using ASA ipsec-l2l tunnel

3. Use an ip helper on a switch in remote site to ensure dhcp lease

4. VPN connectivity works fine, however

5. DHCP is not reachable via VPN

I have attached a diagram to better explain.

Would appreciate any help on this or further clarification on my setup.

[Francesco Molino]

Hi

What do you mean by dhcp isn't reachable over vpn? Do you have connectivity from site 1 (switch) to your dhcp server on site 2? (Test a ping first to validate this).

On your dhcp server, if you run a tcpdump, do you see anything packets coming from site 1?

On asa, do you see the dhcp request passing through on site 1?
Have you validated you aren't filtering out on asa using acl?

Dumb question: the scope for site 1 os created on your dhcp server?

[nwekechampion]

Hi Frnacesco,

Q1. No I cannot get to Dhcp server from switch

Q2. Scope configured

subnet 10.20.1.0 netmask 255.255.255.0 {
range 10.20.1.11 10.20.1.254;
option routers 10.20.1.1;
}

subnet 10.10.1.0 netmask 255.255.255.0 {
range 10.10.1.100 10.10.1.110;
option routers 10.10.1.254;
}

Q3.On ASAs: I have port number 68, client open on on site 01
And port number 67 open on site02

Thanks so much for your help,
Will appreciate any further assistance

[Francesco Molino]

Ok I understand you have opened DHCP ports on both side. But if from the switch you can't ping your DHCP hosted on the remote site, this means the crypto acl used for this L2L VPN isn't allowing the DHCP prefix or maybe a nat issue.
Can you post your firewall configs into a text file for better visibility?

[nwekechampion]

Hi Francesco,

Please see attached.

Both ASa01 for site01 and ASa02 for site02

Many Thanks

[Francesco Molino]

Hi

Your config is ok. I even tested it in a quick virtual lab and it works.

On my site 1, I put a simple VPCS machine and ubuntu with isc-dhcp-server daemon on site 2.

On site 1:

VPCS> ip dhcp
DDORA IP 10.10.1.100/24 GW 10.10.1.1

VPCS> show ip

NAME : VPCS[1]
IP/MASK : 10.10.1.100/24
GATEWAY : 10.10.1.1
DNS :
DHCP SERVER : 10.20.1.50
DHCP LEASE : 468, 600/300/525
DOMAIN NAME : lab.com
MAC : 00:50:79:66:68:07
LPORT : 20000
RHOST:PORT : 127.0.0.1:30000
MTU : 1500

Switch site 1:

interface Vlan10
ip address 10.10.1.2 255.255.255.0
ip helper-address 10.20.1.50

On Site 2 DHCP Server:

user@user-PC:~$ cat /var/lib/dhcp/dhcpd.leases
# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-4.3.5

# authoring-byte-order entry is generated, DO NOT DELETE
authoring-byte-order little-endian;

server-duid "\000\001\000\001%\366\305sP\000\000\006\000\000";

lease 10.10.1.100 {
starts 6 2020/03/07 20:51:09;
ends 6 2020/03/07 21:01:09;
cltt 6 2020/03/07 20:51:09;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet 00:50:79:66:68:07;
uid "\001\000Pyfh\007";
client-hostname "VPCS1";
}

From your switch on site 1, you should be able to ping your DHCP server on site 2 (in my example, site 2 DHCP has ip 10.20.1.50) and vice versa.

SW1#ping 10.20.1.50 so vl 10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.1.50, timeout is 2 seconds:
Packet sent with a source address of 10.10.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/12/23 ms

user@user-PC:~$ ping 10.10.1.2
PING 10.10.1.2 (10.10.1.2) 56(84) bytes of data.
64 bytes from 10.10.1.2: icmp_seq=1 ttl=255 time=30.9 ms
64 bytes from 10.10.1.2: icmp_seq=2 ttl=255 time=22.3 ms
^C
--- 10.10.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 22.369/26.671/30.973/4.302 ms
user@user-PC:~$ ip add

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 50:00:00:06:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.20.1.50/24 brd 10.20.1.255 scope global noprefixroute ens3
valid_lft forever preferred_lft forever

Now we've validated your VPN connection, I believe the issue is on your ubuntu.

Are you using isc-dhcp-server?

Can you make sure the output of the command service isc-dhcp-server status says active (running)?

I hope you configured isc the correct way. I mean ISC, by default, won't serve any IP from a subnet on which it doesn't have any interface sitting in.

Please, share your dhcpd.conf

[nwekechampion]

# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#
# Attention: If /etc/ltsp/dhcpd.conf exists, that will be used as
# configuration file instead of this file.
#

# option definitions common to all supported networks...
option domain-name "site02.lab";
option domain-name-servers 10.20.1.9, 8.8.8.8;

default-lease-time 600;
max-lease-time 7200;

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.

#subnet 10.152.187.0 netmask 255.255.255.0 {
#}

# This is a very basic subnet declaration.

#subnet 10.254.239.0 netmask 255.255.255.224 {
# range 10.254.239.10 10.254.239.20;
# option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
#}

# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.

#subnet 10.254.239.32 netmask 255.255.255.224 {
# range dynamic-bootp 10.254.239.40 10.254.239.60;
# option broadcast-address 10.254.239.31;
# option routers rtr-239-32-1.example.org;
#}

# A slightly different configuration for an internal subnet.
#subnet 10.5.5.0 netmask 255.255.255.224 {
# range 10.5.5.26 10.5.5.30;
# option domain-name-servers ns1.internal.example.org;
# option domain-name "internal.example.org";
# option subnet-mask 255.255.255.224;
# option routers 10.5.5.1;
# option broadcast-address 10.5.5.31;
# default-lease-time 600;
# max-lease-time 7200;
#}

# Hosts which require special configuration options can be listed in
# host statements. If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.

#host passacaglia {
# hardware ethernet 0:0:c0:5d:bd:95;
# filename "vmunix.passacaglia";
# server-name "toccata.example.com";
#}

# Fixed IP addresses can also be specified for hosts. These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP. Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
#host fantasia {
# hardware ethernet 08:00:07:26:c0:a5;
# fixed-address fantasia.example.com;
#}

# You can declare a class of clients and then do address allocation
# based on that. The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.

#class "foo" {
# match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
#}

#shared-network 224-29 {
# subnet 10.17.224.0 netmask 255.255.255.0 {
# option routers rtr-224.example.org;
# }
# subnet 10.0.29.0 netmask 255.255.255.0 {
# option routers rtr-29.example.org;
# }
# pool {
# allow members of "foo";
# range 10.17.224.10 10.17.224.250;
# }
# pool {
# deny members of "foo";
# range 10.0.29.10 10.0.29.230;
# }
#}

subnet 10.20.1.0 netmask 255.255.255.0 {
range 10.20.1.11 10.20.1.254;
option routers 10.20.1.1;
}

subnet 10.10.1.0 netmask 255.255.255.0 {
range 10.10.1.100 10.10.1.110;
option routers 10.10.1.254;
}

[nwekechampion]

Hi Francesco,
Thanks so much for putting in the time to run the config.Please see attached for DHCP Server config  on Ubuntu.

ubuntu@ubuntu:~$ service isc-dhcp-server status
● isc-dhcp-server.service - ISC DHCP IPv4 server
Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor
Active: active (running) since Mon 2020-03-09 05:58:21 UTC; 6min ago
Docs: man:dhcpd(8)
Main PID: 834 (dhcpd)
Tasks: 1 (limit: 1152)
CGroup: /system.slice/isc-dhcp-server.service
└─834 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd

Mar 09 06:03:53 ubuntu dhcpd[834]: DHCPDISCOVER from 0c:38:2f:d4:40:00 (box) via
Mar 09 06:03:53 ubuntu dhcpd[834]: DHCPOFFER on 10.10.1.100 to 0c:38:2f:d4:40:00
Mar 09 06:03:56 ubuntu dhcpd[834]: DHCPDISCOVER from 0c:38:2f:d4:40:00 (box) via
Mar 09 06:03:56 ubuntu dhcpd[834]: DHCPOFFER on 10.10.1.100 to 0c:38:2f:d4:40:00
Mar 09 06:03:59 ubuntu dhcpd[834]: DHCPDISCOVER from 0c:38:2f:d4:40:00 (box) via
Mar 09 06:03:59 ubuntu dhcpd[834]: DHCPOFFER on 10.10.1.100 to 0c:38:2f:d4:40:00
Mar 09 06:04:22 ubuntu dhcpd[834]: DHCPDISCOVER from 0c:38:2f:d4:40:00 (box) via
Mar 09 06:04:22 ubuntu dhcpd[834]: DHCPOFFER on 10.10.1.100 to 0c:38:2f:d4:40:00
Mar 09 06:04:25 ubuntu dhcpd[834]: DHCPDISCOVER from 0c:38:2f:d4:40:00 (box) via
Mar 09 06:04:25 ubuntu dhcpd[834]: DHCPOFFER on 10.10.1.100 to 0c:38:2f:d4:40:00

Please see above as well. It is running as exepected.

[Francesco Molino]

can you put the remote subnet under the shared section and try again please?

[nwekechampion]

Hi Francesco,

Would the below be right please:

shared-network 224-29 {
subnet 10.10.1.0 netmask 255.255.255.0 {
range 10.10.1.100 10.10.1.110;
option routers 10.10.1.254;
}

# subnet 10.17.224.0 netmask 255.255.255.0 {
# option routers rtr-224.example.org;
# }
# subnet 10.0.29.0 netmask 255.255.255.0 {
# option routers rtr-29.example.org;
# }
# pool {

[Cristian Matei]

Hi,

   Assuming your DHCP Relay and DHCP Servers are configured properly, you need to have IP access through your VPN tunnel (so your crypto ACL), between 10.20.1.0/24 and 10.10.1.0/24. From the DHCP Ubuntu Server, ping the IP address configured on Gi0/2 on the switch from the remote side. Does it work?

Regards,

Cristian Matei.

[nwekechampion]

Hi Cristan,

Would the below be correct (on ASA Site02)?

access-list GLOBAL extended permit icmp object NET_Site02 object NET_10.0.0.0
access-list GLOBAL extended permit icmp object NET_10.0.0.0 object NET_Site02
access-list GLOBAL extended permit ip object NET_Site02 object NET_10.0.0.0
access-list GLOBAL extended permit ip object NET_10.0.0.0 object NET_Site02
access-list GLOBAL extended permit tcp any host 10.20.1.10 eq 67
access-list GLOBAL extended permit udp any host 10.20.1.10 eq bootps


On ASA Site01?
access-list GLOBAL extended permit icmp object NET_Site01 object NET_10.0.0.0
access-list GLOBAL extended permit icmp object NET_10.0.0.0 object NET_Site01
access-list GLOBAL extended permit ip object NET_Site01 object NET_10.0.0.0
access-list GLOBAL extended permit ip object NET_10.0.0.0 object NET_Site01
access-list GLOBAL extended permit udp any 10.10.1.0 255.255.255.0 eq bootpc

Thanks so much

[nwekechampion]

Hi Christan,

No it does not work.
it just stops within the LAn and the ASA LAn facing gateway g0/1.

Thanks

[Cristian Matei]

Hi,

    Unless explicitly configured, your decrypted VPN traffic is not matched against your ASA inbound ACL's (like global or interface specific):

       - make sure the VPN is functional

       - make sure the crypto ACL and VPN filter, if configured, allow IP traffic between the two protected subnets, and allows DHCP traffic towards the DHCP helper/server

       - make sure routing is done properly so that the protected networks can reach each other via the VPN tunnel

       - the DHCP server has a route (specific or default) for the subnets it leases addresses (for the pools it uses as a DHCP server), through the VPN tunnel. With DHCP relay, the DHCP messages are unicast, and there needs to be IP connectivity between eh DHCP server IP (its own IP address, so whatever is configured as helper on the other side) and the DHCP Relay agent (for subnets that the DHCP server scopes; so if on the LAN side where the helper is configured you have ip address 10.10.10.1/24, the DHCP server needs to be able reach 10.10.10.1

At this point, you should be able to reach the DHCP server via the VPN tunnel from the other side (test connectivity with ping). At this point check if DHCP allocation works.

Regards,

Cristian Matei.