NAT translation of destination IP before IPSEC VPN

[DekPlent]

Hi All,

Just another question re NAT on a 1590 running 80.20 build 2467:

If I wanted to NAT a destination IP before it was passed into a tunnel, is this possible to do ?

So

Remote server 172.23.56.23 ----via router talks to proxy ARP NAT of 172.17.56.7 on checkpoint which  in turn NATs destination to 10.103.116.24 (from172.17.56.7 ) -------> IPSEC VPN to remote site which has encryption domain of 10.103.116.0/24

The traffic is not being encrypted and passed out the external leg of firewall. The traffic is accepted as shown in the attachment ZAB. If I disable NAT the traffic destined for 10.103.116.24 the traffic is still unencrypted out through external

A directly attached system to  the checkpoint also forwards traffic to 10.103.116.24 but it does not need to NAT the destination, this traffic is encrypted as expected and sent. This is shown in the attachment ZAB2

Does anyone have any tips to troubleshoot this please

Both 172.23.0.0 and 172.17.0.0 are listed in the oneliner to determine the location encryption domain on the checkpoint. ALso the remote VPN endpoint has these networks defined conversely.

Thanks Again

Regards

Dek

[DekPlent]

The relevant output from the encryption domain oneliner:

VPN Gateway > remote office
Encryption domain
10.103.116.0 - 10.103.116.255

VPN Gateway > checkpoint 1590
Encryption domain
172.17.0.0 - 172.17.255.255

172.23.0.0 - 172.23.255.255

[the_rock]

Normally, the matching for vpn domains through the tunnel is done before any nat is performed. So, just to make sure I get this right, what exactly are you trying to nat here? Can you please verify the IP addresses?

Andy

[DekPlent]

Sure Andy,

the remote IP of 10.103.116.24 connected via IPSEC VPN  has a NAT on the checkpoint of 172.17.56.6.   This NAT of 172.17.56.6 is contacted by a remote machine 172.23.56.25

So

172.23.56.26 talks to 172.17.56.6 which the checkpoint NATs the destination to 10.103.116.24...

The checkpoint does this NAT, but in the external interface I see clear traffic going out:

IP 172.23.56.25.47462 > 10.103.116.24.10051

The checkpoint is however encrypting traffic to all of 10.103.116.0/24 when contacted by a system local to the checkpoint

I hope what I have explained,  makes sense

[the_rock]

I think I get it now...so, correct me if Im wrong when I say this, but sounds to me based on your last reply that its not even NAT thats really the issue, its more the fact that you see clear traffic from 172.23.x.x subnet going to 10.103.x.x.

You see the tunnel is up at the moment, correct? If so, make sure that VPN domains indeed consist of right subnets and if so, I would suggest quick fw monitor command for those IP addresses to make sure its taking correct path.

[DekPlent]

Hi Andy,

Yes you are correct that NAT is now working but the traffic is being accepted and not encrypted , I wondered if it was the fact that the destination IP was NATed before being routed.

I will check that for sure. I will see what fw monitor reveals.

Thanks again

[the_rock]

Just make sure that subnet is indeed set for nat, but furthermore, also verify that setting inside the community object is not checked that says "disable NAT inside this community". Sometimes, people may have to actually create manual nat rule in this situation, because technically, if right subnets are part of vpn, then as long as nat rule reflects the correct subnets, there is really no reason why it would fail. Just make sure 100% that nat setting inside community is clear, because if it checked, it would override even if correct nat rules are in place for vpn traffic.

Yes, please do the captures and see what it shows. That would give us really good idea on moving forward.

[DekPlent]

Thanks,

I have attached a screenshot of the disable NAT option. That note underneath seems to suggest that I cannot override?

Maybe in advanced settings there is an option to override.

The remote end is a linux server running libreswan/openswan IPSEC. I wil look to see if a similar option exists.

[the_rock]

Ping me Monday, lets do remote session if you are available.

[DekPlent]

Sure thing, are you east or west coast of Canada?

[the_rock]

East, so we are in est time zone, which is 5 hours behind you. Im free at say 1 pm UK time for 2 hours or after 4 pm UK time.

[DekPlent]

Awesome, that's great.

Thank you

[the_rock]

No worries, happy to help. Just message me directly and we can fire up zoom or webex Monday at say 1 pm your time. Im also free tomorrow after 7 pm UK time for about 2 hours, if you want to do that. Let me know.

[DekPlent]

Hi Andy,

Are there any particular options that you can recommend for fw monitor pkts from IP 172.23.56.25 to 172.17.56.6 to 10.103.116.24 please?

Or options to perhaps point out a non match a VPN encryption domain?

I will have another read in the morning as it's 3am here now in the UK 😕

Thanks again

[the_rock]

I hear ya...I know UK is definitely way more exciting at 3 am than here in Canada, just my personal experience : - ). Anyway, on to topic...

Yes, you can run many filters, say something like this -> fw monitor -e "accept host(x.x.x.x) and port(x);" or fw monitor -e "accept host(x.x.x.x) and host(y.y.y.y) and port(x) and port(y);".

You can also use or instead of and in the captures.

Andy

[DekPlent]

Thanks Andy, hopefully I can get some useful info out

[Timothy_Hall]

To follow up on what @the_rock said about gathering packet captures @DekPlent, depending on your configuration the VPN traffic may be accelerated by SecureXL and therefore will not show up in a fw monitor -e capture.  As detailed in my "Max Capture: Know Your Packets" self-guided video series you can do a fw monitor -F capture which has much more limited filtering syntax but can capture all traffic even if it is accelerated.  The equivalent syntax for the first fw monitor -e example the_rock gave you would be the following where x is the port number and x.x.x.x is the IP:

fw monitor -F "x.x.x.x,0,0,x,0" -F "0,x,x.x.x.x,0,0"  

the second example is a bit tougher but would look like this for port x (you can't do more than five -F expressions in a single command so we can't do port y as well in the same capture):

fw monitor -F  "x.x.x.x,0,0,x,0" -F  "0,x,x.x.x.x,0,0"  -F  "y.y.y.y,0,0,x,0" -F  "0,x,y.y.y.y,0,0"

Just be sure to check your syntax for the -F expressions carefully as it can be rather unforgiving if you make a mistake and either give you nothing or a completely unfiltered capture depending on your code version.

[the_rock]

I totally forgot about that command, thank you @Timothy_Hall , good point! So, @DekPlent , as Tim posted about -F flag, here is what you could do. First example he gave, though this is generally how syntax works anyway, after -F flag, in the quotes, all you need to remember is this sequence...

"source IP, source port, destination IP, destination port, protocol"

So 0 in this example would refer to any port or any protocol. 

You can also use this website (super helpful) that my colleague made for different captures on different vendors:

https://tcpdump101.com/#

So, lets give simple example. Say you are troubleshooting connection between IPs 10.10.10.10 and 20.20.20.20. In that case, even if you did not ports or protocol involved, you would run something like below:

fw monitor -F "10.10.10.10,0,20.20.20.20,0,0" -F "20.20.20.20,0,10.10.10.10,0,0"

You literally switch source/dst IPs in second -F flag involved.

But, Tim is right, if vpn traffic is accelerated, it may not show in regular fw monitor command I gave you. I would also give him big kudos for book he mentioned, its fantastic, I would suggest you buy it, money well spent if you deal with CP constantly ; - )

Im still available for remote Monday if you are up for it.

Have a fantastic weekend!!

[DekPlent]

Thats wonderful Tim, Thanks for the tip, I will try it now. I could only see the INTERNAL traffic from the source hitting the NAT but then nothing relating to the destination IP it is being NATed to.

[Timothy_Hall]

Right so if NAT is involved you need to specify both pre-NAT and post-NAT filters.  So suppose pre-NAT source address is x.x.x.x and post-NAT is z.z.z.z to destination a.a.a.a and you also want to do port 80:

fw monitor -F x.x.x.x,0,a.a.a.a,80,0 -F z.z.z.z,0,a.a.a.a,80,0 -F a.a.a.a,80,z.z.z.z,0,0 -F a.a.a.a,80.x.x.x.x,0,0

[DekPlent]

Thanks very much Tim, I will t ry this to confirm that I can follow the packet through the points. This will be useful for me!

[DekPlent]

Hi Tim,

It seems that -F is not supported with the  build I have installed on the quantum spark appliance R80.20.35 (992002467)

# fw monitor -F 172.56.23.56,0,172.17.56.8,10050,0
fw: illegal option -- F
fw: illegal option -- F

Usage: fw monitor [- u|s] [-i] [-d] [-v vsid] [-X] [-T] <{-e expr}+|-f <filter-file|->> [-l len] [-m mask] [-x offset[,len]] [-o <file>] <[-pi pos] [-pI pos] [-po pos] [-pO pos] | -p all [-a ]> [-ci count] [-co count]

Maybe it is available in 2577?

I can do some research

Thanks again

[Timothy_Hall]

Hmm the -F option for fw monitor was added for the non-SMB gateways in R80.20 Jumbo Take 73.  If it is not available to you I'd recommend using tcpdump as it will capture accelerated traffic the vast majority of the time.

[DekPlent]

Oh I see, I did wonder why some options for fw monitor were not available. I have used tcpdump but only for observing sources and destinations for traffic inbound and outbound from interfaces. The ability of fw monitor for packet inspection inside the VM itself looks very useful.

[Juan_]

Destination NAT is only supported with routed VPN, and not domain VPN:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

I usually ask the counterpart to do the NAT on their side.

Juan

[DekPlent]

Ahh Thanks Juan, Looking at that document that looks like what I am exactly trying to. 😧

@the_rock  looking back, you did state that VPN encryption matching is done BEFORE NAT. So in this case the original pkt comes from  source 172.23.x.x  destination 172.17.x.x  Both are Networks that are in the local encryption domain. I apply the destination NAT and so I can only assume that happens after VPN encryption tagging .. If I am understanding correctly...

These checkpoint 1590s  collapse previously a tier of Cisco PIX and then Checkpoint R71s. Where the cisco tier performed the destination NAT and the checkpoint encrypted and sent via VPN.

[DekPlent]

The document suggests

===============================================================================================

Solution

In addition to the destination NAT rule, add a route-based VPN in order to encrypt the traffic destined to the NATed destination IP.

This setup will cause the packet to be encrypted, as with VTI the decision whether the packet will be encrypted is based on the destination only, and happens on the outbound chain (after the OS IP stack / routing decision), unlike the NAT which is implemented earlier - in the inbound chain.

==============================================================================================

I may look at experimenting with the options as attached to this post

[the_rock]

Correct, I did state that, but I can tell you that from my experience, I never had people create route based VPN to achieve this, it worked fine with regular domain based. I get thats what sk says that @Juan_  posted, but Im not so sure the sk is accurate.

[DekPlent]

It'd be great to figure out a way to get that traffic encrypted .  I looked at the route based solution and it seems to suggest creating VTIs which adds more complexity.

The other option is to specify the encryption domains manually omitting 4 IPs I am using as NATs for the remote VPN including the 10.103.116.x network but including an additional IP used as a hide SNAT for a 2nd VPN ( but the destination IP is not NAT'ed for this VPN hence no problem).  The IPs of the 5 NATs are in the same range as the IP of an interface that the checkpoint already has, hence the range is included the automatic derivation of local encryption domains.

The other option reverses the initial aim not to expose our 10.103.116.0/24 range in that segment of the network in thr first place. This, however, means configuring a number routers and exposing routes back to the 10.103.116.0/24 network which is not desirable.

[d_esTin_y]

I had almost similar situation. Objective was to reach a destination IP behind a domain based VPN, but hiding the original destination towards sending host.

To achieve this added the Original source host network on both  VPN endpoints. Then added the D-NAT IP to the remote gateway encryption domain on local gateway. The remote gateway encryption domain consist then the real remote server and the local D-NAT IP as the source host talks only to D-NAT IP. The article sk116097 describes this situation.