Hi Gert
I assume you are running in tunnel mode and using ESP. I also assume your
IPSec peers are between the WAN links. From your logs, no encryption is done
because the IP header has changed to 19.30.101.17 & 195.30.101.18 as a
result of NAT. You would need to have crypto ACLs for these 2 addresses.
Also, you might want to try NAPT for your 2 servers (192.168.0.10 &
192.168.0.11), which would mean that you will now need 1 tunnel, which makes
things less ugly.
Just my 2 cents (or 2p here in UK)
Alister
-----Original Message-----
From: Gert Doering [mailto:gert@greenie.muc.de]
Sent: 10 July 2001 12:06
To: cisco-nsp@puck.nether.net
Subject: [nsp] IPSEC tunneling and static NAT?
Hi,
today I ran accross an interesting problem.
I have a customer VPN that uses RFC addresses internally (let's call
'em 192.168.0.x/24).
They use NAT to go to the internet, using an address pool and overload,
say, to 195.30.100.0/29 (made up):
ip nat pool EXT 195.30.100.1 195.30.100.6 netmask 255.255.255.248
ip nat inside source list 170 pool EXT overload
with an access-list permitting 192.168.0.0/24.
In addition to this, they have a partner network which is connected
over IPSEC, and uses IP addresses 10.0.0.0/8. The targets are specified
in the crypto map via
crypto map SEC 10
match address 130
access-list 130 permit ip 192.168.0.0 0.0.0.255 10.0.0.0 0.255.255.255
Accordingly, access-list 170 (for NAT) is modified to exclude the
10.x addresses:
access-list 170 deny ip 192.168.0.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 170 permit ip 192.168.0.0 0.0.0.255 any
So far, everything works - 192.168.0.x can reach 10.x.x.x and vice versa.
Now for the interesting stuff. For external connectivity to a handful
of servers, we have *static* NAT entries:
ip nat inside source static 192.168.0.10 195.30.101.17
ip nat inside source static 192.168.0.11 195.30.101.18
and for these servers, IPSEC connectivity to 10.x.x.x does NOT work.
>>From what I have seen by inserting "log" into all the access lists,
what happens is the following:
- 10.x.x.x sends an ping packet to 192.168.0.10
- the ping packet is IPSEC encapsulated and tunneled
- the local router extracts it and forwards to 192.168.0.10
- 192.168.0.10 responds
- the local router NATs this packet to 195.30.101.17
(any "deny" rules of access-list 170 do NOT apply to static NAT!)
- the source address of the packet is no longer 192.168.0.x
- no IPSEC encapsulation is done.
>>From what I have seen in the documentation, there is NO way to qualify
a "ip nat inside source static" translation to apply only for a given
list of outside hosts. Could someone please confirm that this is true,
and in the abovementioned scenario, NAT really breaks IPSEC?
As a workaround, I think I could configure IPSEC to also encapsulate &
tunnel packets sourced by 195.30.101.17 and 195.30.101.18 (external NAT
addresses). But this is severely ugly, as it means
- I run a network with Tunnels and go to IPSEC -> the addresses that
I have to use in the partner network will change (from "talk to
internal IPs in the partner network" to "talk to external IPs
and have them NATted after IPSEC").
- I run a network with IPSEC, which works just fine, and add an
"ip nat inside source static" entry for an entry -> the addresses
that I have to use from the partner network has to change (as above)
which both are prone to make maintenance a nightmare.
Sooo... - is there a solution?
* Using "ip nat inside source route-map..." will not help, as it only
affects dynamic entries (as inside source list ...), not static entries,
and there is no way to get an external->internal NAT translation
with route-maps.
* Using tunnels and applying IPSEC to them might work (but as the other
end is a PIX firewall, I'm not sure whether the PIX can do this - plain
IPSEC works fine).
* using multiple IP addresses for the hosts in question, some of them
being statically NATted, and some of them not, will work for incoming
connections, but for outgoing connections, results are pretty much
random (depending on the IP address used as the source IP).
* using "inside source static 192.168.0.10 195.30.101.17 list 170"
would be a nice idea, but alas, there is no "list 170" qualifier
(12.1(8a))...
frustrated,
gert
-- USENET is *not* the non-clickable part of WWW!//www.muc.de/~gert/ Gert Doering - Munich, Germany gert@greenie.muc.de fax: +49-89-35655025 gert.doering@physik.tu-muenchen.de
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:44 EDT