03-02-2015 04:11 AM - edited 02-21-2020 08:06 PM
Hello Everyone,
I would like to ask for you help on this issue, I tried configuring a separate internal DHCP server for VPN client using Cisco's config guide available.
But have no luck, i am getting the error below;
IPAA: DHCP request attempt 1 failed IPAA: DHCP configured, no viable servers found for tunnel-group 'RAVPNTunnelgroup' |
ASA Version 9.1(2)
!
interface GigabitEthernet0/2
nameif servers
security-level 100
ip address 10.10.2.254 255.255.255.0 standby 10.10.2.253
group-policy AdminGrpPolicy internal
group-policy AdminGrpPolicy attributes
dhcp-network-scope 10.10.3.0
vpn-simultaneous-logins 1
vpn-idle-timeout 180
vpn-session-timeout none
vpn-tunnel-protocol ikev1
tunnel-group RAVPNTunnelgroup type remote-access
tunnel-group RAVPNTunnelgroup general-attributes
authentication-server-group LdapServer
default-group-policy NoAccessGrpPolicy
dhcp-server 10.10.2.1
tunnel-group RAVPNTunnelgroup ipsec-attributes
ikev1 pre-shared-key *****
no vpn-addr-assign aaa
no vpn-addr-assign local
vpn-addr-assign dhcp
03-06-2015 12:10 PM
Hello,
On this case there are various ways to troubleshoot this, firstly the configuration you have applied it's correctly configured, and I could notice you are using LDAP attribute mapping therefore the NoAccessGrpPolicy, go ahead and do the following:
* Make sure you can reach the DHCP server from the ASA with no issues (ICMP works fine for it)
* Once that is confirmed, you can go ahead and set up a local pool to make sure that the connectivity is fine, if the users connect with an Ip address given by the ASA, we will need to run debugs, to make sure what is going on:
DHCP debugs: This will show us error when negotiating with the DHCP server
debug dhcprelay error
debug dhcprelay event
debug dhcprelay packe
IPSec Debugs: This will show us any IPSec issue
debug crypto isakmp 7
debug crypto ipsec 7
on the clients side:
1) Client makes a UDP Broadcast to the server with a DHCPDiscover, or Discover packet.
The interface which is closer to the dhcp server(outside in our case) will intercept the request.
2) DHCP offers to the client. The server sends a DHCPOffer including other configuration parameters (DHCP Options) for the client per the servers configuration file
3) In response to the offer Client requests the server. The client replies DHCPRequest requesting the offered address. The DHCPRequest is a broadcast message not a unicast one, see packet #4 in the above captures. According to RFC2131 for DHCP, the reason why the request is broadcast is to implicitly decline offers from all other servers while requesting the IP assigned by one of the servers.
4) The server sends DHCPAck acknowledging the request which is the clients final permission to take the address as offered. Before sending the ack the server double checks that the offered address is still available, that the parameters match the clients request and (if so) marks the address taken.
* If you know and apply all of these we will be able to determine what the issue is.
* Take a look to these 2 links:
- https://supportforums.cisco.com/blog/149511
- http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/109493-asa-vpn-dhcp-asdm-config.html#configurationRAVPN
Please don't forget to rate and mark as correct the helpful Post!
Let me know how it works out
David Castro!
Regards,
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