- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
10-02-2015 09:00 AM
Hello,
Just curious if anyone has had to go throug this and found a solution.
layer3 switch <-> Cisco ASA <-> VPN <-> PAN <-> DHCP server
I know the ASA does some funky stuff and uses the 'outside' interface to forward the packets so on the other side you have to do some funky rules. I've been successful with doing this with two ASA's, but I dont even see the traffic on the PAN side when the ASA is configred properly per Cisco documentation.
Yes I can use the layer 3 switch to forward the packets and this should work, still testing, but was curious about the config on the PAN side if the ASA is doing the relay.
Thanks in advance!
10-08-2015 03:21 PM
Success! As it runs out, there was a bug in the ASA that when I wrote an ACL that was too specific (just the dhcp protocols), it wouldnt hit on that particular rule. So I made the rule wide open (all protocols), and it started working. Once I verified, I tightened it back down and its still working.
Here is the setup for both sides:
ASA:
(DHCP relay commands)
dhcprelay server <DHCP server IP> <Name of external interface>
dhcprelay enable <Name of internal interface>
dhcprelay setroute <Name of internal interface>
dhcprelay timeout 60
(The external interface IP must be added to the VPN tunnel crypto map, I used an object group but an IP will also work)
access-list <Name of crypto Map> extended permit ip object-group <Name of object group or IP address> any
PAN:
Add the ASA's external IP address to the Tunnel config Proxy ID's so it matches the ASA's
Allow traffic between the zones since I used a different zone for the remote office
I'm glad that adventure is over!
10-05-2015 08:48 AM
Hi,
If you set ip-helper address on cisco it should forward dhcp request to this ip.
Do you see dhcp packets coming from zone your vpn tunnel interface is set to?
Information about DHCP relay
But you probably don't need to set relay on Palo as ip-helper should be unicast not multicast traffic so there is destination IP set to your destination DHCP server already.
Cheers,
Raido
10-05-2015 09:28 AM
Yeah I have the helper setup. I didnt setup any dhcp relay's on either the PAN or the ASA since I dont think it needs them? The helper address should just send the request over the VPN to the DHCP server on the other side.
10-05-2015 11:07 AM
Yes it should.
Is your vpn tunnel interface in dedicated zone?
What do you see if you filter Traffic log with following filter (change vpn zone to the one your tunnel interface is in)?
( zone.src eq vpn-zone ) and ( app eq dhcp)
10-08-2015 07:55 AM
So the newest weird twist is that the DHCP server is seeing the packets but sending them back to the 'internal' interface of the ASA instead of the 'external' as per the cisco documentation.
The ASA is seeing the encrypted dhcp requests but not any returning. The PAN see's the packets from the ASA and they are returning to the 'internal' interface of hte Cisco.
I'm sure the answer is a PBF rule of some kind, but so far no luck.
Gotta love interopertability....
10-08-2015 03:21 PM
Success! As it runs out, there was a bug in the ASA that when I wrote an ACL that was too specific (just the dhcp protocols), it wouldnt hit on that particular rule. So I made the rule wide open (all protocols), and it started working. Once I verified, I tightened it back down and its still working.
Here is the setup for both sides:
ASA:
(DHCP relay commands)
dhcprelay server <DHCP server IP> <Name of external interface>
dhcprelay enable <Name of internal interface>
dhcprelay setroute <Name of internal interface>
dhcprelay timeout 60
(The external interface IP must be added to the VPN tunnel crypto map, I used an object group but an IP will also work)
access-list <Name of crypto Map> extended permit ip object-group <Name of object group or IP address> any
PAN:
Add the ASA's external IP address to the Tunnel config Proxy ID's so it matches the ASA's
Allow traffic between the zones since I used a different zone for the remote office
I'm glad that adventure is over!
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!