Hi everyone, I'm looking for some clarity regarding proxy-ID behavior for Palo Alto appliances. Hopefully I can make my question simple and explain the set up clearly.
Essentially, we have an IKE Gateway and IPSec tunnel set up that terminates to another PAN appliance. Let's say we are Company A and they are Company B.
IKEv1 Gateway set up between Company A (188.8.131.52) and Company B (184.108.40.206). This comes up successfully.
There are proxy-IDs set up for this tunnel and the local addreses for these are actually a subnet that we NAT our internal nodes to.
IPSec tunnel (interface tunnel.1) with proxy-ID local address of 10.218.0.0/29 and remote address of 10.252.0.1/32.
We have static routes on our side that forward traffic destined for the far-side internal IP of 10.252.0.1 through the tunnel interface. We recently brought up a new node (10.1.1.3) that needs to communicate with Company B's node of 10.252.0.1 but did not have a NAT for this initially (ie. NAT'ing 10.1.1.3 to fall within the local proxy-ID subnet, say, 10.218.0.3). Our traffic logs showed that 10.1.1.3 was indeed sending traffic (sent bytes) over the tunnel, even though it didn't match any local proxy-ID, but was not receiving any reply traffic from 10.218.0.3 (received bytes). Company B's logs showed that they were receiving our traffic over the tunnel and were replying, we just weren't "receiving" it.
The fix for this, which thankfully I figured out rather quickly, was that we were missing a NAT. Once I set up a bidirectional NAT for 10.1.1.3 to 10.218.0.3, we started "receiving" their traffic as shown in 'received bytes'. This was the only change made on both sides in order to resolve this issue. It seems that we were dropping their traffic since it was not matching any proxy-IDs and hence logs showed no received bytes, at least, that's my current assumption/understanding.
So my main question is, if proxy-IDs determine what traffic is 'allowed' over the tunnel and must match exactly on both sides, why is it that our traffic from 10.1.1.3 was indeed being sent and received while their traffic was being sent and dropped on our end?
I expected that since our traffic didn't match any proxy-IDs (on the local address), our sent traffic would be dropped and they should not have seen anything coming in.