I have created a tunnelled static route in the ASA to push all VPN data to the Internal firewall.
However there are some hosts behind this internal firewall that require access to VPN clients, how do I set this up as I am seeing that if I ping a VPN client host form a server behind the intenral firewall this is reaching the external firewall..
Do I need to setup policy based routing? Is there a way to setup a route in the ASA to push traffic from behind the internal firewall to the vpn client.
1) do the AnyConnect clients get an IP address from a pool on the ASA?
Yes the VPN IP address is assigned from pool on the ASA
2) does the internal firewall have a route for the address pool on the ASA?
Yes I have configured a route in the internal firewall to route the IPs from the VPN pool to the ASA
3) am I understanding your description and drawing correctly in believing that from the internal firewall you must go through the ASA to get to the external firewall?
From the internal firewall VPN clients will go through a proxy and out a different firewall which I have not drawn on the diagram.
All clients VPN into the Cisco ASA which acts as a gateway to the internal network behind the firewall. This aspect is fine and the client is able to talk to hosts in the internal network however when a server attempts to talk to a client from behind the firewall it is not reaching the client and it is going down the default route of the ASA which sends it up to the externa firewall (effectively the WAN)
4) are you doing any address translation on the addresses in the address pool of the ASA?
I have the following NAT rules
Manual NAT Policies (Section 1)
1 (INTERNAL-FW) to (ASA WAN) source static any any destination static VPN_SUBNET VPN_SUBNET no-proxy-arp route-lookup
Thanks for the information. It is helpful to know that VPN clients can successfully communicate with hosts in the internal network. But it makes me more confused about why servers are not able to communicate with VPN clients. What address is the server using when it attempts to communicate with the VPN client?
Are you sure that the traffic from the servers attempting to get to VPN client is going through the ASA default route to the external firewall? Are you actually seeing on the external firewall the traffic from the servers? I am wondering if it might be an issue is access policy and access rules on the ASA that is allowing traffic from internal to VPN address pool when it is a response but is not allowing traffic to initiate from internal to the VPN address pool?
What address is the server using when it attempts to communicate with the VPN client?
It is using the vpn client address i.e the 172.x.x.x address that is assigned to the client upon successfull vpn initiation
Are you sure that the traffic from the servers attempting to get to VPN client is going through the ASA default route to the external firewall?
Yes because I ran a packet trace on the external firewall and I could see the traffic destined for the 172.x.x.x address hitting the external firewall.
Are you actually seeing on the external firewall the traffic from the servers?
Yeah I am seeing an attempted icmp for example from an internal server sitting behind the firewall reach the
- Internal Firewall - route from the static route i created to the vpn clients
- ASA - route through the default route through its interface connected to external firewall (btw the vpn termination point is the same interface connected to firewall)
I assume that when the client initates traffic to the internal server this works because the asa knows about the session and recieves server reples via the session it knows about. However when the server iniates the traffic the asa does know know about this session so it sees the destination as a raw IP and not one from the VPN pool?
I am wondering if it might be an issue is access policy and access rules on the ASA that is allowing traffic from internal to VPN address pool when it is a response but is not allowing traffic to initiate from internal to the VPN address pool?
I do have an ACL filter associated to the tunnel group for the VPN which allows the VPN client access to various subnets behind the internal firewall.
In the ACL I do also have allowed in the incoming acl for inteface connected to firewall for internal subnet to talk to vpn clients on any any for now
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.