06-17-2016 02:56 PM - edited 03-12-2019 12:54 AM
Hello Forum Folks!
I'm working on a problem I feel should be easy, but I'm just not able to get my head wrapped around it. Our network is configured something like this:
Outside 1.1.1.1 (Security lvl 0)
Inside 192.168.1.0/24 (Security lvl 100)
OtherInside 192.168.2.0/24 (Security lvl 50)
(numbers have been changed to simplify the configuration)
I currently have an SSL remote access VPN configured. When I VPN in from outside, I'm able to access hosts on the Inside network, no problem. Unfortunately, when I try to access any hosts on OtherInside, I'm unable to reach them over the VPN.
I have VPN connections allowed from the inside network as well so I can show my users how to connect to the VPN. For testing purposes, I connected to the VPN from the inside and lo and behold, I was able to access OtherInside!
This does not make sense to me for two reasons. The sysopt for VPN traffic to bypass the ACL table is in the default enabled state and the tunnel is configured for full tunneling. The group policy applies no filtering either. Based on this, it seems to me that the ASA should not care which interface I'm initiating the tunnel from since it's processing all host traffic and ACLs are ignored since it's VPN traffic.
I'm not sure if packet tracer can be of much help here, since I'm not sure how to express that the source traffic is from the RA VPN. Similarly, I'm not sure what source interface to specify in a pcap to try to capture the traffic. Captures of egress traffic do not show anything being passed by the ASA.
There are not any sourcefire rules that appear to be likely to interfere, and disabling the service policy that inspects the traffic didn't affect the behavior.
Hardware is an ASA 5516-X running firmware 9.5(2)6.
Can anyone provide any insights into what I can check next or how I can generate packet tracers or capture files that will prove instructive?
06-17-2016 07:43 PM
Hi,
The easiest way forward is to configure the
management-access
Now from the Anyconnect client try pinging the OtherInside interface IP and use debug
Check whether the pings are able to make it to the interface.
Are you using any NAT rules for this VPN traffic ?
If yes can you share the sanitized config ?
Regards,
Aditya
Please rate helpful posts and mark correct answers.
06-20-2016 12:12 PM
Aditya,
Sorry for the delay in my response. I was unable to work on the issue over the weekend.
Following your troubleshooting steps, I changed the management-interface to otherinside. After completing that, I was able to ping the ASA interface assigned to the OtherInside network, but was still unable to ping the other hosts on that network. The network off otherinside has no routers behind it, it is a simple /24 network and the clients have no routes configured on them beyond the default route.
The only NAT that affects the OtherInside network is the standard "catchall" PAT configuration. Here is the NAT rule:
object network DynamicPat_CatchAll
nat (any,outside) dynamic interface
This is the same catchall PAT rule that applies to our Inside network which works as expected over the tunnel, so I'm hesitant to believe that this is the cause of our concerns, but I'm not positive.
Let me know if there are any ptracers or pcaps you need to explore this more deeply. If you still would like to look at the NAT config or any other section, let me know and I'll sanitize and post it.
Thanks!
Aaron
06-21-2016 09:05 AM
Hi,
I hope you have added the 192.168.1.0 as a part of the split tunnel access-list under the group-policy.
Regards,
Aditya
Please rate helpful posts and mark correct answers.
06-21-2016 01:17 PM
Aditya,
I've got the tunnel currently configured as a full tunnel. We have a lot of road warriors and a full tunnel helps protect their traffic even on insecure Gogo or Starbucks WiFi. As such, there should be no split tunnel ACL to be concerned with. (Please correct me if I'm wrong on that!)
Just to be explicit (in case I'm missing a setting to make it full tunnel!) I have the RA VPN group policy inheriting from the default and the default is configured for "Tunnel All Networks" in ASDM.
Thanks,
Aaron
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