03-04-2020 08:24 PM
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.
03-04-2020 08:41 PM
03-05-2020 06:38 PM
03-05-2020 08:30 PM
03-06-2020 01:30 AM
03-07-2020 01:01 PM
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
03-08-2020 11:01 PM
03-08-2020 11:06 PM
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.
03-09-2020 07:13 PM
03-09-2020 09:33 PM
03-05-2020 03:21 AM
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.
03-05-2020 06:44 PM
03-06-2020 01:18 AM
03-10-2020 06:53 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide