New PA200 installed and working on getting it setup. Aside from a 2wk demo, I have little experience with PAN.
I've got a Site-To-Site VPN configured to an ASA5505 at another of our offices.
I have one zone setup for a Wifi network. (Called Wifi) IP space behind that zone is 22.214.171.124/24. Interface 1/3 is configured with the IP 126.96.36.199 PAN is providing DHCP for this network.
Client behind this network has a DHCP address of 188.8.131.52 with a subnet mask of 255.255.255.0
On the other side of tunnel.1 (this interface is tagged as the Remote zone) is the IP space 10.5.0.0/16. Client behind that firewall has IP 10.5.1.25/255.255.0.0.
I have Security Policies configured to allow traffic between the zones.
However, pinging between the clients routes through the wrong rule (Default rule allowing outside access) instead of the Wifi-to-Remote or Remote-To-Wifi rules (depending on which side I'm pinging from)
I can ping from the CLI of the PAN to any client in the Remote zone.
And I can ping from any client in the Remote zone to the 184.108.40.206 address of the PAN.
Since it wasn't working with the zones defined, I changed the Source/Destination of the rules to the specific IP ranges of the zones in the security rules.
(I've also tried putting in the range directly, 220.127.116.11-18.104.22.168, with the same result)
Now in the Monitor->Traffic tab, the Wifi-Client to Remote-Client (and vice versa) ping shows up in the correct rule, but the ping still doesn't complete (Request Timed Out)
I'm sure there's something relatively simple that I've missed, could someone point it out for me?
Solved! Go to Solution.
Worked with support for several hours yesterday.
Found that I'd left a PBF that was preventing local from following the rest of the rules I'd set in place. Doh!
Now I'm pinging from local to remote, but not from remote to local.
We're staring at config files on the ASA to see what we missed.
Two static routes in the VR:
0.0.0.0/0 with ISP gateway as next hop on outside-facing interface
10.5.0.0/16, no next hop, tunnel.1 interface
Edit to add: I tried adding a next hop of 10.5.1.1 (Remote gateway) to no avail.
Assuming you have the IPSEC Tunnel, IKE Gateway, IPSEC Crypto, IKE Crypto configured correctly.... This looks to be a routing issue. What does a tracert look like from a client on one side to a client on the other side? Where does it stop?
Does the Zones belog to the same virtual router? If not, even with correct security rules, traffic won't flow.
In static route you need only net and interface tunnel.1, no next hop
Also pay attention to secuty acls, use zones, not the enforced network until connection is ok.
Is the remote side configured to send the traffic (destined to 172.168.1.x) through its tunnel interface as well?
You said: Since it wasn't working with the zones defined, I changed the Source/Destination of the rules to the specific IP ranges of the zones in the security rules.
Assuming you did have a static route for remote subnet pointing to the tunnel.1 interface (remote zone), the traffic must match the Wifi-to-Remote rule, unless the default outbound rule is above this specific rule ignoring it.
You can also try taking pcaps on the remote side and verify if they are receiving our packets and responding back to us.
traceroute from the Remote site fails. Both too the PAN (22.214.171.124) and to the client (126.96.36.199). Even though ping to the PAN works.
from the local site to the remote site fails. No hops.
Since there's 'nothing' between the clients on each side of the VPN, I'm not surprised there isn't anything showing in a traceroute.
I am surprised that traceroute is failing from Remote to the PAN, since the ping works.
All the interfaces of the PAN are in a single VR. It's the only VR on the PAN.
The default rule to allow out-bound traffic is at the bottom of the stack. The rules to allow from local-to-remote and remote-to-local are located above that default rule.
Presently only have 3 rules in the PAN.
Cisco is routing traffic to 188.8.131.52/16 across the tunnel.
In order to troubleshoot this, I would recommend creating a deny all rule at the bottom with alerts (any zone to any zone with just alerts) so you can see what is being implicitly denied. It sounds like you have 2 rules for traffic from "local" to "remote" and from "remote" to "local", and a third from "local" to "external". With those rules, you will not be able to view the implicit denies in the traffic log, so it will be harder to troubleshoot unless you want to do it from the CLI.
Adding the Deny-All rule seems to have broken everything, but I'm not able to ping from either side across the VPN either(even after disabling the Deny-All rule, just to test). Not sure what I broke there.
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 Live Community as a whole!
The Live Community thanks you for your participation!