As I cannot connect to the ASA to initial any traffic for testing purposes, so I simulated the settings on our 2 PAs.  The diagram is   172.16.4.241 is natted to 123.103.202.111 192.168.55.250 is natted to 78.152.42.166   SYD-PA config is 1. static routing to 78.152.42.166 point to the tunnel interface 2. outbound security policy is from trust zone 172.16.4.241 to ipsec zone 78.152.42.166, allow any 3. Inbound security policy is from IPsec zone 78.152.42.166 to trust zone 123.103.202.111, allow any 4. NAT policy is from trust zone to ipsec zone, 172.16.4.241 source NAT to 123.103.202.111, bi-direction is yes   LDN-PA config is 1. static routing to 123.103.202.111 point to the tunnel interface 2. outbound security policy is from trust zone 192.168.55.250 to ipsec zone 123.103.202.111, allow any 3. Inbound security policy is from ipsec zone 123.103.202.111 to trust zone 78.152.42.166, allow any 4. NAT policy is from trust zone to ipsec zone. 192.168.55.250 source NAT to 78.152.42.166, bi-direction is yes   my testing result on syd sw, ping 78.152.42.166 from 172.16.4.241,   ping failed. I can see the ping log on SYD-PA and the log detail shows the NAT was triggered.   I cannot see any logs from/to 123.103.202.111 on ldn-pa I started a pcap on ldn pa and I can see the icmp packets in drp.pcap and rcv.pcap   I've no idea where the issue is...   ... View more

hello @AlexanderAstardzhiev  hello @AlexanderAstardzhiev  "The PAN FW has nothing to do with 5.5.5.x addresses, isn't this the whole purpose of the GRE tunnel? - Packets from the client will enter the router - Which will add GRE encapsulation, which boilse down to a new IP header - Now the outer IP header (that is used for routing decisions) is has different source and destination addresses - more specifically your GRE tunnel addresses, right? - When the packet reaches the PAN FW and if you don't apply any tunnel content inspection it will see only the 3.3.3.3 and 192.168.55.250." ---------------This is exactly what I thought. When 192.168.20.34 sending a packet to the 5.123.111.144, the traffic flow should be (my understanding, please correct if anything wrong) Original packet send to GRE device S:192.168.20.34 D:5.253.111.144 GRE tunnel encapsulates the original packet by adding an extra header, so  the source/destination IP in the packet changes to S: 192.168.55.250    192.168.20.34 😧  3.3.3.3                    5.153.111.144 My firewall NAT the 192.168.55.250 to 4.4.4.4 then send the packet towards to the IPsec tunnel, ipsec tunnel add extra header S: 1.1.1.1    4.4.4.4   192.168.20.34 😧  2.2.2.2   3.3.3.3    5.153.111.144 The ASA removes the IPSec header and delivers it to the other side GRE device S:  4.4.4.4   192.168.20.34 😧  3.3.3..3   5.153.111.144  The other side GRE device removes the GRE header and delivers the original packet to the server S:  192.168.20.34 😧   5.153.111.144 I thought we should be able to see the log on PA from 192.168.55.250 to 3.3.3.3 but I cannot. Why? I took a pcap on the PA, the packet I got is, but cannot see it in the log     ... View more

hello @AlexanderAstardzhiev  for stage 2, what I want to achieve is 1. the tunnel IP can ping each other, 5.5.5.6 <> 5.5.5.5 2. the client 192.168.20.34 is able to ping 5.123.111.144   for 1: I need to add static routing on PA for dest 5.5.5.5, point to the ipsec tunnel interface and add static for my side tunnel IP 5.5.5.6, point to internal interface, as before adding the routing entry, the PA goes to 5.5.5.0/24 via the default route to the internet So the outbound security policy should be trust zone > ipsec zone source 5.5.5.6 to dest 5.5.5.5 inbound security policy should be ipsec > trust zone source 5.5.5.5 to des 5.5.5.6 is this correct?   for your question about stage2  Or your want to "hide" the client ip behind 5.5.5.6 and the server behind 5.5.5.5? --- exactly. I have static routing "ip route 5.123.111.144 255.255.255.0 tunnel 2" on my switch, so when my client 192.168.20.34 pinging 5.123.111.144, the GRE switch will add extra header S:5.5.5.6 D:5.5.5.5 before the raw packet header S:192.168.20.34 D 5.123.111.144   So I dont need to create policy for 192.168.20.24 <> 5.123.111.144 as the packet header has been changed after the packet leaving the tunnel towards to PA. I hope I am making sense(excuse for my bad English) ... View more