We've got a location where we want to setup a VPN-tunnel to our HQ.
At that location, there's a router which does PAT (NAT overload), and then, some hops further, there's a firewall which does NAT.
Could this pose a problem to the VPN-tunnel?
Here's a 'diagram' of what the connection looks like.
Client -->PAT-router-->NAT firewall-->Internet-->CVPN3005
Hopefully you can provide me with an answer.
Solved! Go to Solution.
i don't think there would be an issue.
one thing should be noticed is when a host from the cvpn site needs access the the remote site, than a static nat needs to be configured on the router.
ok, that's a plus.
If I'm not mistaken, the tunnel uses UDP-port 500 and UDP-port 4500 if I'm using NAT-T (which I must because of the NAT at the firewall).
Could there be more ports needed because of the PAT and NAT?
Is that correct? When using NAT-T as far as I know ESP is encapsulated in the traffic on UDP-port 4500?
ESP or AH cannot be NATted, as far as I know...
What if the client would be a PIX, and I would set up port forwarding on the PAT-router (port UDP 500 and UDP 4500 to PIX)?
PIX --> PAT-router --> NAT-firewall --> Internet --> CVPN3005
The VPN-tunnel I want to use is IPSec with NAT-T (have to, because of at least 1 NAT-device) from a PIX to a CIsco VPN Concentrator.
I think, though, that I've already gotten my answer in that it won't work.
Because of the PAT _and_ NAT, the port-translations and info that reaches the CVPN will all be screwed up.
Doing port-forwarding on the PAT-router is not going to be the best solution.
I've just had a talk with a technician of the networkoperator, and he confirmed that it will not work. They can do something to eliminate 1 of the NAT/PAT-devices, so I think that's the way to go.
private net <--> pat router <--> nat firewall <--> www/vpn <--> cvpn
maybe it would be better if we put some ip into the scenario.
192.168.1.0 <--> pat router <--> 192.168.2.0 <--> nat firewall <--> www/vpn <--> cvpn <--> 192.168.0.0
1. a host with ip 192.168.1.100 attempts to access a server with ip 192.168.0.100.
2. pat router receives a packet originated from 192.168.1.100 and destined for 192.168.0.100.
3. pat router performs pat, i.e. translates the original source from 192.168.1.100 to the router outside interface 192.168.2.1 with port 2647 (i.e. a random port assigned by the pat router)
4. nat firewall receives the packet with source ip 192.168.2.1 and destined for 192.168.0.100.
5. nat firewall has no nat statement, such as "access-list no_nat permit ip 192.168.2.0 255.255.255.0 192.168.0.0 255.255.255.0", thus no nat/pat will be performed.
6. nat firewall matches the packet with the crypto acl, encrypts/encaps the packet and forwards the packet down the lan-lan vpn.
7. the cvpn receives the packet, decaps/decrypts and forwards the packet to the server with ip 192.168.0.100.
8. server replies. nat firewall receives the packet, decaps/decrypts and forwards the packet to the pat router.
9. pat router receives the packet originated from 192.168.0.100 and destined for 192.168.2.1 with port 2647.
10. pat router verifies its translation table. it matches the existing translation, so the pat router translates the packet destination ip from 192.168.2.1 back to 192.168.1.100.
please excuse me for my so-called "interpretation" above. it may not be very clear, but i believe this scenario should work.
in fact, i have implemented a similar scenario and it works fine. below is the simiplified topology:
private net <--> pix (pat) <--> pix (pat/no_nat) <--> www/vpn <--> cvpn <--> private net
This would indeed work, because the NAT-firewall is not a NAT-firewall in your scenario.
In the case I have, I have no control over the router or the firewall, so this is no option for me.
As you put it, you effectively have a client behind a NAT-router (PAT = NAT overload) connecting to the VPN concentrator through the internet. You're effectively ruling out the firewall in your scenario.
please excuse me for misunderstanding.
you mentioned, "The VPN-tunnel I want to use is IPSec with NAT-T (have to, because of at least 1 NAT-device) from a PIX to a CIsco VPN Concentrator."
thus i have the impression that the vpn is between the pix and the cvpn. so the vpn termination point, which i've asked for verification couple times, is not the pix.
again, i'm so confused. are we discussing remote vpn by using cisco vpn client, which behind a pat router, and a nat firewall?
VPN is from a PIX or Software VPN-client to a VPN Concentrator.
That would indeed mean that the termination-point is the Concentrator.
It doesn't matter is the initiating (starting) client is a PIX or a VPN Client, since the type of tunnel is the same, and the devices in between are the same. You could see a PIX as a hardware VPN Client... Only difference is that it is a Multi-client VPN Client (gateway)...
But again, by not doing NAT on the firewall as you do, the situation is completely different.
so finally i guess i understand the picture; one termination point is the cvpn, and the other termination point is a device, that is deployed behind both a pat router and a nat firewall.
assuming this time i got it right, then, as you already know, this solution is not feasible.
having a second thought, it's embarrassed to say, but now i disagree to my previous post. there should not be any drama with your scenario. please allow me to show you couple examples.
one of our branch offices runs on cable. the isp assigns a private ip on the cable modem as well as the router.
branch private net <--> pat router <--> cable modem <--> isp nat/pat device <--> www
due to the fact that the isp assigned ip is always private, i believe once the packet destined for the internet arrives at the isp cloud, and before it gets outside, the isp needs to pat/nat the packet as the source ip is private, right? yet, users from this branch are able to establish vpn to our main office cvpn.
other example is cdma with pcmcia card for notebook. again the isp assigns a private ip on the pcmcia card. thus, before the packet leaves the isp cloud, another pat/nat is required.
these two examples indicate that the remote vpn client is able to establish and maintain a vpn tunnel to a cvpn, regardless whether there is another nat/pat device along the path.
further, isn't the aim of nat traversal is to overcome the issue with pat/nat? in simplified terms, the cvpn receives a udp packet and starts processing. the cvpn and then realises that esp is being encapsulated by udp. next, cvpn decrypts and examines the packet further in order to validate the packet (with the original source ip regardless the udp header source ip).
In this scenario, I believe the following is the case.
A modem cannot obtain an IP-address; it is always a bridge between a device and a network. This means the router obtains an address from the ISP through the modem.
Generally, the obtained IP-address is a public IP-address (I know of no other setup thatn that), thus the ISP doesn't habe to do NAT or PAT. Mostly, the ISP doesn't even have a firewall in between the client-router/modem and the internet.
I say a modem canot obtain an IP-address, because a modem is for signal-conversion only; it does not make decisions.
For example, a telephone-modem is used for initiating the connection. Your computer gets an IP-address through your modem.
In a router, a connection-device (Ethernet, DSL-WIC) does have an IP-address.
That's because the router has to know what addresses are connected, i.e. what exits it has. However, the router has the IP-addresses, not the actual interface.
n the case of the branch office, what is the IP of the router and modem? And what IP-address do internet-sites see?
I think they are all one and the same...
By the way, NAT-T is indeed for fixing problems with NAT-devices. However, even in the documentation of the Concentrators, they state that it will only work if either one or both sides are each behind a (single) NAT-device. That has to do with the port-translations and encapsulation of the IP-addresses. If a single device is behind multiple NAT-devices, the source IP-address wil be altered too many times, and will therefore be the wrong one when it reaches the endpoint.
firstly, thanks for giving me a network fundamental. i guess i understand the BASIC of ip and how does it work, otherwise it would be a shame to be one of the top netpros.
believe it or not. the router deployed at the branch office has a private address on the outside interface. and that's why this particular branch has no lan-lan vpn back to our office, but rely on the remote vpn client software. further, as mentioned in my last post, the cdma pcmcia card is another example. i.e. the notebook will be assigned a private ip by the isp.
for your info, the branch router has a 192.168.x.x ip; whereas the cdma notebook has a 10.x.x.x. if the host do a search on google "current ip", a public ip will be shown. further it changes from time to time.
you mentioned "the obtained IP-address is a public IP-address (I know of no other setup thatn that)". please excuse me, but i guess it maybe time for you to make a trip to australia.
at the end of the day, if you believe the scenario will not work. that's fine. thanks for sharing.
just another quick comment.
for testing purposes, a pix 501 has been deployed behind a pix 515e.
my notebook <--> pix 501 <--> sw <--> pix 515e <--> router <--> www
pix 501 outside: 192.168.0.100
pix 515e outside: 203.x.x.x
both pix 501 and pix 515e are configured to perform pat, and my notebook is able to establish a vpn and it works normally.
Can you just explain why a router is placed before a PIX and what that sw means in your message.
And its really amazing that the above scenario is working!