IPSec and PROXY ID

[Alex_Samad]

Hi

Some back ground - been a long time since i delved into ipsec + proxyid. back in the linux days with strongswan and openswan and there was issues with nat and ipsec.

My understanding back then was you had a interface say eth0 and when you applied a IPSEC tunnel (so ESP not AH)

the proxyid were used to identify what was encapsulated into the ESP tunnel and what wasn't - I think there was also a time there was a separate interface created

Now to the palo world

so there is an interface that phase 1 terminates on

and there is a interface for phase 2, i presume anything that goes into the tunnel gets encrypted (again only ESP).

No my understanding is that proxy id is a filter that let PA decide what packets go into the tunnel interface - if it matches it goes through and if it doesn't it doesn't go through

To me its a bit like a security thing apply a proxy id to allow/dissallow what I want through.

I see the doco from pa talking about Policy base vs routing to me doesn't matter. if I only expect to get 10.1.1.0/24 from the other end - I'll force proxyid remote for 10.1.1.0/24 my presumption is that any other packets will get dropped.

This is the interesting thing - the other end i am dealing with now is a cisco - checking their doco ... OMG. routing happens before the SA's/IPSEC stuff so seems like packets can get on there that by pass the proxy id - seems like its acceptable -- can't be bothered to read the RFC. And the person on the other end I am talking to suggest - not sure how that works but that the packets will be un encrypted.  not sure how that works either.

the implication is say in my example

eth1 - pa interface

tun1 is the ipsec tunnel interface

proxyid local 10.0.0.0/24 remote 192.168.0.0/24

if I send a packet down tunnel 1 with src 10.0.0.1 dst 192.168.0.1 the proxy id will allow it and it will enter tun1 (ignore any firewall polices) and be encrypted

if I send src 10.10.10.10 dst 192.168.0.1   that will not match the proxy id and I believe that the packet will get dropped not allowed into the tunnel.  I think on the pa you can do with the  a ping and setting interface and src ip ! i think - definitely can do weird stuff with Linux to test this. Also note I have said anything about routing lets presume I have BGP and the other end is sending 0/0

Is this true does the packet that doesn't match the proxy id get filtered out or does it go through !

If it goes through is it the tun1 interface and does it get encrypted .. and if this is through what the hell does proxy id do?

[GOMEZZZ]

Hi,

Personally I would avoid using Proxy-ID's if possible.  But if you don't have another choice because your remote end only supports policy based VPN's then you will have to deal with them.  If you have a route based VPN a proxy ID of 0.0.0.0/0 is used on the background if hou do not configure anything.

When using proxy ID's if they don't match the tunnel will simply not be formed so no traffic will pass. Each proxy id establishes a tunnel.

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClUFCA0

Proxy-ID add complexity and if possible I would use your policy to allow or disallow traffic. 

But sometimes you don't have choice, depends on you case.
So if no proxy id match no tunnel will be formed an no traffic will pass.

I hope this clarifies a little bit you question.

[Alex_Samad]

Hi

Thanks for replying but i think you are missing my point - its not about policy based or route based.

Its also not about missed matched proxyid.

what happens to packets that are not part of the proxyid when they are sent via the tunnel - do they get dropped because they are not part of the tunnel - which I think they do - which i think is good as it allows you to filter what traffic goes through

does it go through un ecrypted - don't think that possible

thanks

[aleksandar.astardzhiev]

Hi @Alex_Samad

You said - "talking about Policy base vs routing to me doesn't matter".

But it actually matter a lot!

Have you every think what  "sending traffic through the tunnel" actually means? You know there is not actual separate physical pipe you send traffic. "Sending traffic through the tunnel" means to tell the firewall to encrypt the  traffic with and slap the  additional headers.

Policy-based VS Route-based VPN is all about how the decision to encrypt or not is taken.

Palo Alto firewalls are applying only route-based VPN - This means that decision if received packet should be encrypted or not is taken based on the routing table lookup. If there is a route pointing to the logical tunnel interface that is matching the destination in the packet, firewall will send this packet for encryption.

IPsec standards dictates that packet still need to match the negotiated proxy-ids (encryption domains as called by other vendors). If you routing table send packet for encryption, but it does not match the proxy-id (that has been negotiated with the remote site), packet will be dropped.

For that reason Palo Alto recommend to use "wildcard" proxy-id (0.0.0.0/0) for local and remote whenever it is possible (when supported by remote side of the tunnel).

With route-based VPN if traffic doesn't match the route to the VPN it will take one of the other routes in your routing table, possible taking the default - meaning traffic will not be encrypted and send to your ISP, where it most probably will be dropped because the destination is private IP

Regarding the Cisco at the other end and the "unencrypted" statement by the other engineer:

- Although Cisco routers/FWs can support both route-based and policy-based. Based on your explanation it seems they are applying policy-based VPN.

- Similar to Palo, Cisco will also perform route lookup, however it will not have route pointing to any tunnel interface (because there is not such think as tunnel interface when you have policy-based VPN). Instead traffic will take the default route

- On the outside interface of the Cisco device there will be applied the VPN policy - defining/matching which source and destination IPs should be encrypted and to which peer it needs to go (what headers needs to be added).

- This is achieved by using access-lists (ACLs). Those ACLs are used to define proxy-ids for the VPN tunnel.

- If traffic matches those ACLs it will be encrypted, slapped with additional header and forwarded via the outside interface

- If traffic doesn't match ACLs/proxy-ids traffic will be simply forwarded via the outside interface without encryption. Again eventually dropped by the ISP as destination is most probably private IP

[Alex_Samad]

Hi

Sorry missed your reply so this

"

IPsec standards dictates that packet still need to match the negotiated proxy-ids (encryption domains as called by other vendors). If you routing table send packet for encryption, but it does not match the proxy-id (that has been negotiated with the remote site), packet will be dropped.

"

So you are saying the PA does this if it doesn't match the proxy-id it will fail.

so if I set my end up properly and I limited what the other end can send - but they screw up their routing I can enforce it from my end and not get packets from the other end that I don't want.

[Raido_Rattameister]

Palo Alto don't care about ProxyIDs if it comes to routing traffic.

If there is route to the tunnel and tunnel is up then traffic is sent to the tunnel.

ProxyID on Palo side is only to make other end happy if other end uses policy based vpn mode.

ProxyID needs to match exactly in case of IKEv1 but not so much with IKEv2.
For example to establish IKEv2 tunnel to Meraki device that has more than 1 subnet Palo side must be set to 0.0.0.0/0 due the way Meraki combines multiple ProxyIDs (traffic selectors) into single one.

https://documentation.meraki.com/MX/Site-to-site_VPN/IKEv1_and_IKEv2_for_non-Meraki_VPN_Peers_Compar...

Also traffic coming from tunnel and not matching ProxyID is not dropped.

Security policies are used for that.

[Alex_Samad]

So you are saying PA don't follow the IPSEC standard as stated in the comment I replied to

and you are also stating that if packets don't match proxy id they don't get dropped (that one is strange as I have tested this and that patently false )

[Raido_Rattameister]

Can you point out the standard you are referring to.

https://datatracker.ietf.org/doc/html/rfc7296#section-2.9

"It also allows for intentionally different
configurations, as when one end is configured to tunnel all addresses
and depends on the other end to have the up-to-date list.

When the responder chooses a subset of the traffic proposed by the
initiator, it narrows the Traffic Selectors to some subset of the
initiator's proposal (provided the set does not become the null set)."

[Alex_Samad]

Hi

I was quoting aleksandar.astardzhiev its the post i initiall replied to above

and in fact yours is stating the same thing, i believe if the packet doesn't match the proxy id it gets dropped

it lines up with what I see in linux and its ipsec setup.  I did spend a lot of time looking at it then - its been a while since I read the doc on it.

So in my mind it seems silly - in the spec to say - yeah you can say what ip address ranges you would like - but hey we will ignore it if the packets doesn't match and just let the packet through any way - like we would for any packet that does match.

if I have control over what can be sent down the IPSEC tunnel, why wouldn't i want undesirable packets to be dropped on the other end in stead of making it to my end of the tunnel

UPDATE-

Had a quick read over - still think its saying what I am saying.

I also tested from my end so lets say I have

route 10.95.0.0/24 routed through the IPSEC tunnel

10.95.2.1 &2 are used on the ipsec tunnel interfaces

if i have proxy id set to 0.0.0.0/0

I can ping 10.95.2.1 & 2 and 10.95.0.50

if I set the proxy id to 10.95.0.0/16

I can ping both

if I set the proxy id to 10.95.0.0/24

I can no longer ping 10.95.2.1 or 2 -

I haven't changed the route table just the proxy id

so 10.95.2.1 or 10.95.2.2 doesn't match the proxy id and therefore isn't allowed encrypted and therefor isn't in the ipsec tunnel - note I have done a packet capture to verify that .. works similiar to how I remember on linux

[Raido_Rattameister]

I still stick to my words that Palo don't care about ProxyID. Not for traffic entering into tunnel or coming from it.

I did quick test to prove it.

[Alex_Samad]

Cool, I did my tests previously that should it was blocking it - sorry can't do now as its in prod.