VPN Site to Site traffic - ALLOWED even if there is defined A SPECIFIC proxy id

[TheRealDiz]

Hi All,

First of all enviroment's specific:

panOS 7.1.7

PA 3050

The "strange behavior description":

1. VPN S2S between PA and third party vendor

2. Usual configuration

3. Proxy id:

VTI: Tunnel.103

Local: 10.48.0.0/13

Remote: 10.64.22.176/28

4. Strange behavior --> Remote network 10.64.22.176/28 is able to reach 10.64.29.0/24 that is NOT defined as our local proxy id

**Note: 10.64.29.0/24 is a network that is related with ANOTHER IPsec tunnel behind tunnel.65

How this is possible? I never seen a similar behavior before.

I miss something or do you agree that is NOT a normal behavior?

Thanks in advance,

Luca

[santonic]

I guess you are not filtering much with firewall rules? 

PA is not too fussed about proxy-IDs, it just uses them to establish phase 2. After that it receives anything that comes through tunnel I think. And also sends anything into tunnel (per routing table, regardless of source IP). There is no CheckPoint like behavior 'this packet should (not) be encrypted and therefore is dropped'

[TheRealDiz]

Assuming this ... How can make sense to configure proxy id?!

So IPsec SA generated for specific network allows everything you want? Well done...

[TranceforLife]

@santonic very valid point. PA is a route (interface) based vpn, so all traffic routed to the tunnel interface gets encrypted. Where policy based one (as the name says) traffic gets encrypted according to a defined policy (an access list). Which device is on the other end? 

[santonic]

Nope, PA uses firewall rules to filter traffic. Not SAs. Or enforcing policy by routing.

[TranceforLife]

The best way l think to put tunnel interface to the separate zone and then control the traffic flow by policy as @santonic mentioned

[TheRealDiz]

On the other end probably Fortinet.

If it's like you both told me @TranceforLife @santonic, I'm a little bit disappointed.

I don't care about Checkpoint, Fortinet etc.

Also I don't care about routing:

You have to configure a specific "tunnel interface". So each VPN tunnel as a dedicated "tunnel interface" and a dedicated route.

On my side it's a simple a concept:

Define encryption domain between two firewalls = define IPsec security association for specific networks

You told me that:

Define encryption domain between two firewalls = define IPsec proxy ids. Then if there is a route for a network which is NOT included in the proxy id defined, and obviuosly a security policy that allows the traffic flow.. Well go everywhere you want

Sorry but from the bottom of my experience.. I'm like 😮

[reaper · Accepted solution]

The proxy ID's are implemented for compatibility with policy based vpn peers as they can only setup phase2 if you provide specific subnets

The PANW firewalls are route based, so they set up a tunnel as if it is a normal (zone based) interface and then you route traffic to it and set security policies to control which applications are allowed to traverse the tunnel

If both ends of the tunnel are route based, the proxyIDs are obsolete

[BPry]

@reaper and everybody else pretty much somed this up for you already; but essentially since PA is route based the only reason to include proxy ids is so policy based appliances can actually connect. Generally I like to put my tunnels into there very own zone, then most security policies built for remote offices will include most if not all of the zones, but it allows me to easily filter out traffic if a remote office doesn't need access to something else, like say certain file servers. 

[TheRealDiz]

Thx all of you for the explanation @reaper @BPry @TranceforLife @santonic.

I know that is a route based (zone based) firewall but everytime I have configured proxy ids, I suppose (wrongly) PA would do something implicitly that denies traffic which is not included in the proxy ids defined. I suppose that was a "complete integration" with a VPN policy based firewall.

"The proxy ID's are implemented (ONLY) for compatibility with policy based vpn peers" --> Is there something  explicitly written inside documentation? Or just starting from the fact that is route based, PA doesn't take care about "proxy ids"?

Many many thanks again to all of you 🙂

D!Z

[TheRealDiz]

Further @reaper I got your point:

https://live.paloaltonetworks.com/t5/Configuration-Articles/Security-Policies-Based-on-Zone-Assignme...

😄

[TranceforLife]

yes excellent explanation by @reaper

[reaper]

i cant take credit for that article as it was written by @jperry1 😉

[BPry]

So according to the 7.1 guide the only place that it actually mentions this is in the following paragraph. Everywhere else that a curosry glance at it just kinda indicates that you only need it for policy based peers. 

If you are setting up the Palo Alto Networks firewall to work with a peer that supports policy‐based VPN,
you must define Proxy IDs. Devices that support policy‐based VPN use specific security rules/policies or
access‐lists (source addresses, destination addresses and ports) for permitting interesting traffic through an
IPSec tunnel. These rules are referenced during quick mode/IKE phase 2 negotiation, and are exchanged as
Proxy‐IDs in the first or the second message of the process. So, if you are configuring the Palo Alto Networks
firewall to work with a policy‐based VPN peer, for a successful phase 2 negotiation you must define the
Proxy‐ID so that the setting on both peers is identical. If the Proxy‐ID is not configured, because the Palo
Alto Networks firewall supports route‐based VPN, the default values used as Proxy‐ID are source ip:
0.0.0.0/0, destination ip: 0.0.0.0/0 and application: any; and when these values are exchanged with the peer,
it results in a failure to set up the VPN connection.

[BPry]

Interestingly enough now I'm wondering if setting the info on the Cisco path to make the proxy-ids match routing 0.0.0.0/0 would allow the tunnel to form up properly; I'll have to haul out my 5506-x and give it a test. 

P.S: If you think this is a bad insight the 5506-X currently can't create a BVI (major new feature added in the latest release for 5505 feature parity) and actually route IPSec traffic to the BVI, it creates a VPN-Handle-Error and until the last update forced the device to run out of memory and crash. Makes me want use it to hit my Cisco rep across the head.