topic Re: GRE over IPSec with NAT in General Topics

GRE over IPSec with NAT

DongQu — Tue, 27 Apr 2021 15:24:48 GMT

hello everyone

I am here again.

Referring to the following diagram, My client need to talk with the server 5.123.111.144.

stage 1, to get the GRE tunnel working.

My current is

1. the IPSec tunnel is up.

2. I am using a Cisco router as the GRE device, the tunnel config is

interface Tunnel2
description GRE
ip address 5.5.5.6 255.255.255.0
tunnel source 192.168.55.250 >>>>>>>>>>>>>this IP will be natted to 4.4.4.4
tunnel destination 3.3.3.3

3. the security policy for the GRE tunnel is

trust zone > ipsec zone, source IP 192.168.55.250, dst IP 3.3.3.3

ipsec zone > trust zone, source IP 3.3.3.3, dst IP 192.168.55.250

4. NAT policy

trust zone > ipsec zone, source IP 192.168.55.250 source NAT to 4.4.4.4, bi-direction is yes.

till now, when I ping the tunnel dst 3.3.3.3 with source IP 192.168.55.250, I can see the ping log on the PA and the log showing 192.168.55.250 is being translated to 4.4.4.4, but the ping is failed. I cannot see any packet from 3.3.3.3 in the log. what the issue could be?

stage 2, get my client be able to talk with the server 5.123.111.144.

whats the security and NAT policy should be?

Thank you.

Re: GRE over IPSec with NAT

aleksandar.astardzhiev — Wed, 28 Apr 2021 07:01:03 GMT

Hi @DongQu ,

Your NAT for the "stage1" seems fine. The outbound rule also seems ok, but it the inbound rule is incorrect.

I used to look at my notes every time when I was about create NAT rule:

"NAT rule must be configured with pre-NAT zones (zones matching the addresses before the NAT)
Security rule must be configured with pre-NAT addresses, but post-NAT zones"

This means that your inbound rule should be:

ipsec zone > trust zone, source IP 3.3.3.3, dst IP 4.4.4.4 (dst zone after the NAT, but dst IP before the NAT)

Unfortunately this will not solve your ping problem. The inbound rule will allow you remote site to initiate traffic, but should not have any effect on the return traffic for your outbound pings. If you see the "allow" log with correct NATed source it sound your rule, nat and route are correct (if the route was not correct I wouldn't expect rules to match the dst zone)

- Do you see the counter for encrypted packets increasing while you are pinging? What about the decrypted packets?

- In the traffic log what is the counter of "packets send" and "packets received"?

- Can you check on the ASA if the counters of encrypted and decrypted packets are increasing?

About the second part of your question - I really don't understand what you want to achieve... From the diagram I understand that you will bring GRE tunnel between two Cisco routers. This traffic will be routed through IPsec tunnel between ASA and PAN FW. What I don't understand is what are "tunnel IP 5.5.5.5" and "tunnel IP 5.5.5.6". Is this another tunnel inside the GRE? Or your want to "hide" the client ip behind 5.5.5.6 and the server behind 5.5.5.5?

Re: GRE over IPSec with NAT

DongQu — Wed, 28 Apr 2021 11:29:09 GMT

hello @aleksandar.astardzhiev

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)

Re: GRE over IPSec with NAT

aleksandar.astardzhiev — Thu, 29 Apr 2021 08:10:24 GMT

Hi @DongQu ,

I am probably missing something... 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 new IP header

- Now the outer IP header (that is used for routing desicion) is has different source and destintion addresses - more specificaly 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.

Re: GRE over IPSec with NAT

DongQu — Fri, 30 Apr 2021 13:28:03 GMT

hello @aleksandar.astardzhiev

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

Re: GRE over IPSec with NAT

DongQu — Fri, 30 Apr 2021 13:33:34 GMT

Re: GRE over IPSec with NAT

DongQu — Mon, 03 May 2021 14:26:17 GMT

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...