topic Re: Source and Destination NAT at the same time in General Topics

Source and Destination NAT at the same time

Neo.The.One — Tue, 04 Nov 2014 11:58:01 GMT

Hallo

Before going to my question, please assume the following scenario:

There is a Non-Palo Alto Firewall in internet (lets call it FW-Extern). There is another Non Palo Alto Firewall inside my network (lets call it FW-intern). The FW-Extern initiates IPSec VPN to FW-Intern. The VPN connections are always initiated by the FW-Extern in the direction of FW-Intern on the public IP of FW-Intern.

Now, I put a Palo Alto Firewall (lets call it PA-FW) between these two Non Palo Alto Firewalls. The PA-FW, should allow all this IPSec traffic between these two Non Palo Alto firewalls. The VPN tunnel should NOT terminate on PA-FW.

The FW-Extern has a Dynamic Public IP.

The FW-Intern, has a public IP address (lets say, for example, 1.2.3.4) and a private IP address (lets, say, for example, 192.168.1.1).

So when PA-FW, receives the connection for the IP 1.2.3.4, it performs destination NAT and changes the destination IP to 192.168.1.1.

Note that the PA-FW has an interface called e1/1, which is connected to the FW-Intern and that interface on PA-FW has an IP of 192.168.1.5.

Question:

Now there is a new requirement that when the PA-FW forwards packets to FW-Intern, then the PA-FW should also do Source Address Translation and change the source address to 192.168.1.5. (which is of its interface)

This means that the FW-Intern should talk only to PA-FW, and the FW-Intern has no idea about any external world.

How should the NAT, Security Policy and Routing for such a scenario configured?

Thanks!!

Re: Source and Destination NAT at the same time

ssharma — Tue, 04 Nov 2014 13:13:49 GMT

Hi Amit,

FW-Extrn has dynamic IP address which might cause the issue here. Assuming it has static ip say 4.5.6.7, you can configure following NAT :

Untrust to Untrust if source address is 4.5.6.7 and destination is 1.2.3.4 translate source (dynamic ip-and port to interface e1/1 192.168.1.5) and destination to 192.168.1.1

But since source address keeps on changing and it is the one which initiates vpn traffic, inbound NAT cannot be configured as desired. Hope this helps. Thank you.

Re: Source and Destination NAT at the same time

HULK — Tue, 04 Nov 2014 13:20:43 GMT

Hello Amit,

As per my understanding from the above explanation, while PAN-FW will pass that traffic to FW-Intern it will be look like:

Source Address: 192.168.1.5

Destination Address: 192.168.1.1

Lets assume, PA connected with FW-Extern through "UNTRUST: security zone and ethernet-1/1 connected with FW-Intern is TRUST zone.

You should configure the NAT as:

From zone UNTRUST

To zone UNTRUST

Thanks

Re: Source and Destination NAT at the same time

Neo.The.One — Tue, 04 Nov 2014 13:29:09 GMT

Hi Hulk,

Thanks for your reply!

This is exactly what I have done. However this is not working. The connection seems to go to the FW-Intern, but the return traffic is the problem!

How about Routing and Security Policies?

Re: Source and Destination NAT at the same time

HULK — Tue, 04 Nov 2014 13:29:42 GMT

Hello Amit,

> You will also have to enable NAT-Traversal on both FW-Intern and FW-Extern firewalls, sine the packet is getting NAT'd in the path.

> The FW-Extern always should be the VPN initiator.

> VPN should be configured in aggressive mode.

Hope this helps.

Thanks

Re: Source and Destination NAT at the same time

HULK — Tue, 04 Nov 2014 13:36:27 GMT

Hello AMit,

Routing is not required in your FW-Intern, since, source and destination belongs to the same subnet, instead it will do an ARP lookup to send traffic back to PA-FW. In PAN FW, you may try to configure a policy as:

Source zone: Untrust

Destination Zone: Trust ( ethernet-1/1)

Destination address: 1.2.3.4

Application -ANY

Service- AN

Action- allow

Before initiating the VPN, i would suggest you to check the normal connectivity between PA-Extern and PA-Intern through PING.

Thanks

Re: Source and Destination NAT at the same time

ssharma — Tue, 04 Nov 2014 13:37:55 GMT

Hi Amit,

Your security policy should say from Untrust to Trust to destination 1.2.3.4 allow. Your routing should be good as you have a host route already for interface E1/1 and a default route of 0.0.0.0

Next step would be to do a pcap for the traffic in question and see if anything is getting drop.

Re: Source and Destination NAT at the same time

HULK — Tue, 04 Nov 2014 13:51:29 GMT

Hello Amit,

During the connectivity check, you may follow the session details to ensure NAT, policy lookup is happening in PAN firewall correctly.

Please check the real time session in the CLI by using 'show session all filter source IP_ADD_OF_THE_FW-Extern destination IP_ADD_OF_THE_DESTINATION'.

> If there is a session exist for the same traffic, then please apply CLI command PAN> show session id XYZ >>>>>>>> to get detailed information about that session, i.e NAT rule, security rule, ingress/egress interface etc.

Hope this helps.

Thanks

Re: Source and Destination NAT at the same time

Neo.The.One — Tue, 04 Nov 2014 14:34:15 GMT

Hi all,

Thanks for your replies.

As suggested by all, the security policy and routing are in place. However still stuff does not work.

HULK : In the command show session all filter source IP_ADD_OF_THE_FW-Extern, the problem is that IP_ADD_OF_THE_FW-Extern is dynamic and unknown.

Moreover, I cannot administer Non Palo Alto Firewalls and so I cannot ping between the 2.

Re: Source and Destination NAT at the same time

HULK — Tue, 04 Nov 2014 14:43:18 GMT

Hello Amit,

It is not necessary to track the session based on both source and destination address. You may track it based on only destination address, port 500 /4500, protocol-ike etc.

Thanks

Re: Source and Destination NAT at the same time

ssharma — Tue, 04 Nov 2014 14:47:26 GMT

Hi Amit,

Like HULK suggested , you can only look for destination

show session all filter destination 1.2.3.4

This should give you ike and ipsec application in the session information and you can look for source address is there. I assume, these source will be there for another hour or 2 at least. In the mean time you can run pcap capture to see if firewall is dropping anything. If not, you can explore other avenues for troubleshooting. Hope this helps. Thank you.