- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
03-16-2017 07:15 AM
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
03-16-2017 09:05 AM
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
03-16-2017 07:23 AM
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'
03-16-2017 07:30 AM
Assuming this ... How can make sense to configure proxy id?!
So IPsec SA generated for specific network allows everything you want? Well done...
03-16-2017 07:33 AM - edited 03-16-2017 07:36 AM
@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?
03-16-2017 07:38 AM - edited 03-16-2017 07:40 AM
Nope, PA uses firewall rules to filter traffic. Not SAs. Or enforcing policy by routing.
03-16-2017 07:40 AM - edited 03-16-2017 07:40 AM
The best way l think to put tunnel interface to the separate zone and then control the traffic flow by policy as @santonic mentioned
03-16-2017 07:51 AM
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 😮
03-16-2017 09:05 AM
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
03-16-2017 10:15 AM
@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.
03-17-2017 02:55 AM
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
03-17-2017 03:12 AM
03-17-2017 03:38 AM
yes excellent explanation by @reaper
03-17-2017 03:56 AM
i cant take credit for that article as it was written by @jperry1 😉
03-17-2017 05:50 AM
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.
03-17-2017 09:44 AM
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.
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!