What did I miss? Cross-zone/vpn traffic

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

What did I miss? Cross-zone/vpn traffic

L3 Networker

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 172.168.1.0/24. Interface 1/3 is configured with the IP 172.168.1.1 PAN is providing DHCP for this network.

Client behind this network has a DHCP address of 172.168.1.10 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 172.168.1.1 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.

Wifi-To-Remote:

Source: 172.168.1.0/24

Destination: 10.5.0.0/16

Remote-To-Wifi:

Source: 10.5.0.0/16

Destination: 172.168.1.0/24

(I've also tried putting in the range directly, 172.168.1.1-172.168.1.254, 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?

1 accepted solution

Accepted Solutions

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.

View solution in original post

18 REPLIES 18

L4 Transporter

Have you added the static routes in the VR's routing table?

The inherent vice of capitalism is the unequal sharing of blessings; the inherent virtue of socialism is the equal sharing of miseries.

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?

The inherent vice of capitalism is the unequal sharing of blessings; the inherent virtue of socialism is the equal sharing of miseries.

L3 Networker

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.

Hey Nathan,

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.

Thanks,

Aditi

traceroute from the Remote site fails. Both too the PAN (172.168.1.1) and to the client (172.168.1.10). 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 172.168.1.0/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.

The inherent vice of capitalism is the unequal sharing of blessings; the inherent virtue of socialism is the equal sharing of miseries.

I'll add that rule.
I don't mind working via the CLI, just don't know my way around there.

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.

The Deny rule at the end of the allows should not have broken anything if you have the correct allow rules above it. As I'm sure you know, the rules are applied in order, and there is an implicit deny rule at the end that blocks everything that is not explicitly allowed. If your rules are:

src-zone: WiFi  --> dst-zone: Remote, any source ip, any destination ip, any service, any application, allow (defualt profile)

src-zone: Remote --> dst-zone: WiFi, any source ip, any destination ip, any service, any application, allow (defualt profile)

src-zone: WiFi  --> dst-zone: External, any source ip, any destination ip, any service, any application, allow (defualt profile)

src-zone: any  --> dst-zone: any, any source ip, any destination ip, any service, any application, deny (alert profile)

All traffic should be allowed to 3 zones. However, you will also need to allow the traffic for the IKE exchange between the Remote location's Peer IP address and your Peer IP address. I assume that these are both their external IP, and your external IP. For example:

We have an IPSEC tunnel between a server on our site and a server on a partner site. In order for the tunnel to be open, we have a rule that says:

src-zone: external --> dst-zone: external, src-IP: 156.x.x.x, dst-IP: 26.x.x.x, application <app list>, service application default, allow (default profile)

Even though our Server resides in the DMZ, the tunnel is built between the external interface on our PAN the external interface of the other site's ASA.

Anyway, you should be able to see what is being blocked in the traffic log with the block rule in place with an alert profile and the "log at session end" check box checked. This will allow you to see what the traffic flows are and what is being blocked, which will allow you define your rules to fit.

The inherent vice of capitalism is the unequal sharing of blessings; the inherent virtue of socialism is the equal sharing of miseries.

Here's the rules I have now, in this order:

src-zone: Wifi --> dst-zone: Remote, any source ip, any destination ip, any service, any application, allow (no profile)

src-zone: Remote --> dst-zone: Wifi, any source ip, any destination ip, any service, any application, allow (no profile)

src-zone: External --> dst-zone: External, <PAN public IP>, <Cisco Public IP>, any service, any application, allow (no profile)

src-zone: Wifi -> dst-zone: External, any source ip, any destination ip, any service, any application, allow (no profile)

src-zone: any -> dst-zone: any, any source ip, any destination ip, any service, any application, Deny (no profile)

From a client behind the Cisco, I can ping the PAN's inside IP (172.168.1.1) but not a client behind the PAN (172.168.1.10)

From a client behind the PAN, I can't ping the Cisco internal IP (10.5.1.1 which is pingable from internal) , or the client behind it (10.5.1.25)

tracert from behind the PAN goes outside (both by looking at IPs and from checking traffic log on the PAN)

traceroute from behind the Cisco never completes, but doesn't go outside.

Ping from behind the Cisco to the PAN logs as Remote-to-Wifi rule in the PAN.

Under the system log, are you seeing the all of the vpn negotiations coming back  as successful? Use the filter ( subtype eq vpn ) to see just the vpn traffic.

Also, in the traffic log are you seeing any denies? - use the filters ( app eq not-applicable ) or ( action eq deny ) to see the traffic that is being blocked.

Just in case you haven't reviewed yet - there is a document on IPSEC to ASA located here:

https://live.paloaltonetworks.com/docs/DOC-2579

The inherent vice of capitalism is the unequal sharing of blessings; the inherent virtue of socialism is the equal sharing of miseries.

All vpn attempts are successful.

Blocked traffic is one of two lines:

date/time, drop, from: External, to:External,source:<PAN public IP>, destination: <ISP DNS server>, to port: 53, application: not applicable, action: deny, rule: Deny-All, bytes: 84

date/time, drop, from: External, to:External,source:<PAN public IP>, destination: <Internal DNS server>, to port: 53, application: not applicable, action: deny, rule: Deny-All, bytes: 84

Traffic from Wifi, which should have gone across the VPN was being directed outside until I changed from the destination zone to the ip range of the far side of the VPN. Now it flows through the rules correctly, but still fails to ping.

Traffic from Remote across the vpn to client behind the PAN flows through the rules properly, but fails to ping either.

Thank you for the example/walk-through. I'd not found that one, only an older one dealing with PANos 3.x which was different enough to be not very helpful to this newb.

Accounting for minor differences in config, my ASA config matches that in the example.

If you have your Proxy IDs set to /24s on PAN and /24s for ASA for protected traffic, and exempted NAT from the ASA side, I don't know why this is not functioning. Since the tunnel is up, and the traffic is supposed to be protected and allowed, I am at a loss as to why this isn't working for you. Hopefully someone else will chime in, or you might want to open an incident with TAC.

The inherent vice of capitalism is the unequal sharing of blessings; the inherent virtue of socialism is the equal sharing of miseries.
  • 1 accepted solution
  • 6982 Views
  • 18 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!