06-30-2013 04:16 AM - edited 03-11-2019 07:05 PM
Dear All,
Could somebody cast their eye over this?
We are running and IPSEC VPN tunnel to a client Firewall that we do not have access to. We have and ASA5510 running 8.4 code.
The DHCP server resides on the inside interface of the client firewall on the far end. The Client PC's that require IP addresses reside on our ASA on the inside interface.
We have a site to site VPN configured and we can ping all devices and DHCP servers across the VPN (VPN is working). However, we cannot get the client PC's to obtain an IP address across the VPN.
Our config look like this:
interface e0/0
ip address 213.8.x.x 255.255.255.224
nameif outside
security-level 0
!
interface 0/3.199
ip address 10.1.13.254 255.255.255.0
nameif inside
security-level 100
!
object network VLAN199
subnet 10.1.13.0 255.255.255.0
!
object network COLO
subnet 10.1.99.0 255.255.255.0
!
object network VLAN199
nat (inside,outside) dynamic interface
!
!
nat (inside,outside) source static VLAN199 VLAN199 destination static COLO COLO
!
!
access-list L2LVPN extended permit 10.1.13.0 255.255.255.0 10.1.99.0 255.255.255.0 ///crypto acl
!
!
dhcprelay server 10.1.99.1 outside
dhcprelay server 10.1.99.100 outside
dhcprelay enable inside
dhcprelay setroute inside
/// I have excluded crypto config from this output
We see the DHCP discover messages hit the ASA but we never see anything else. Any ideas?
Appreciate any feedback on this.
Rob
06-30-2013 06:06 AM
Hi,
I have not tested this setup myself but might at some point.
In the meanwhile I'll link this blog post on this Firewall Blog section about this matter.
It was done with the earlier (8.2 and earlier) software versions.
Maybe it will give some ideas
- Jouni
07-01-2013 12:44 PM
Hi,
I moved the DHCP Relay service down to the Layer2 switch, configured helpers and the ip default-gateway had to be in the same vlan as this vlan on the layer 2 switch (otherwise dhcp replies won't work). It was the only way in the end.
Regards
Rob
07-02-2013 12:08 AM
Hi Robert,
The configuration for the DHCP relay across the Site to Site tunnel was not correct and that's the reason why it was not working
In the crypto ACL you need to add the outside ip to the DHCP serevr as well
and the Vice versa on the remote end
So the correct Crypto acl would have been like this
access-list L2LVPN extended permit ip 10.1.13.0 255.255.255.0 10.1.99.0 255.255.255.0
access-list L2LVPN extended permit ip host 213.8.x.x 10.1.99.0 255.255.255.0
Since you already have the inside network in the crypto ACL so we are not adding the inside interface otherwise we would have to add that as well.
Basic understanding of the DHCP relay
1. Client starts the DHCP process by sending a DHCPDISCOVER message to destination address
255.255.255.255 - UDP port 67
2. ASA sees the broadcast and based on the dhcprelay server config it forwards the DHCPDISCOVER
message as a unicast packet to the server's IP sourcing from the interface IP close to the server.
In this case the outside IP address.
3. Server sends back DHCPOFFER as a unicast packet to the ASA - UDP port 67
Server will send it to the destination IP address of the inside interface (giaddr) which is the
dhcprelay enabled interface.
4. This packet will arrive on the outside interface and will be broadcast out the inside interface - UDP port 68.
5. Client receives the DHCPOFFER, and sends a DHCPREQUEST message to the server, that it accepts the offer.
6. The server will send back a DHCPACK message to the client.
7. Client upon receiving the DHCPACK, it will start communicating on the network.
This is how the DHCP relay would work across the site to site tunnel.
HTH!!!
Regards
Raj Kumar
Please rate all helpful posts
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