IPsec, L2TP, Split tunneling, PPTP and all other VPN related posts.
private net <--> pat router <--> nat firewall <--> www/vpn <--> cvpnmaybe it would be better if we put some ip into the scenario.e.g.192.168.1.0 <--> pat router <--> 192.168.2.0 <--> nat firewall <--> www/vpn <--> cvpn <--> 192.168.0.01. 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.