I've got several sites with IPSEC tunnels built between PIX firewalls to encrypt/sign the traffic moving between the "inside" networks on those firewalls. These sites use identity nat where every inside address is directly natted to the same address on the outside i.e. STATIC(inside, outside) 10.164.4.0 10.164.24.0 netmask 255.255.255.0.
But I've just added a new site where things are different. The WAN link terminates on the inside of the firewall and there are hosts on the outside we want to reach. These remote hosts are statically NATed to inside addresses, and our inside interfaces are Dynamically NATed to an outside address, i.e. static (outside, inside) 172.26.14.36 10.164.2.100 netmask 255.255.255.255 global (oustside) 15 172.26.14.15 netmask 255.255.255.255 nat (inside) 15 0.0.0.0 0.0.0.0
Can I define an IPSEC tunnel that terminates on the inside interface that carries traffic to/from an address on the same subnet as the interface?
The attached diagram may make this clearer.
Assuming this is possible I would think on the "local" PIX firewall I could create an acl to define the interesting traffic: access-list newsite-vpn permit ip 10.75.34.0 255 255.255.0 host 10.164.2.100 and use it for VPN.
on the "remote" firewall, would the access-list look like: access-list newsite-vpn permit ip host 10.164.2.100 10.75.34.0 255.255.255.0?
I'm just not clear on where in the "flow" the IPSEC tunnel handling is. I'm assuming it's between the interface and any NATing and access rules.
It looks like the local network that you want to encrypt is in front of the ASA, relative to the 10.75.34.0/24 subnet. If someone on the 10.164.2.96/27 subnet wants to send data to the 10.75.34.0/24 subnet, I imagine they send it to the next hop router, not to the ASA.
I don't think the NAT comes into play, as it is used to make the .100 server on the inside network appear to have an address on the outside network of the ASA.
Given the current infrastructure, the most logical place to put the VPN tunnel endpoint on the local side is on the router (.97). The cleanest solution, if possible, is to use the routers as VPN tunnel endpoints on both ends, given that the PIX running v6.3 at the remote site is obsolete. The routers would have to support VPN with hardware encryption.
If you have to make it work with what you already have, could you create a separate subnet connecting the ASA to the .97 router? That way, devices on the 10.164.2.96/27 subnet could use the ASA as the (new) default gateway for everything, then you could create a VPN tunnel using the new interface on the ASA as a tunnel endpoint.
We don't control the router, so the configuration is sort of stuck as it is.
I was hoping that since the 10.164.2.100 is not a physical device, but a NAT of the actual server we are trying to reach, that the tunnel would work.
The connection flow would be
10.75.34.121 initiates a connection to 10.164.2.100.
Firewall A sees the traffic, builds the tunnel with 10.164.2.125, and ships the encapsulated packet along.
Firewall B decrypts the packet, and says "oh, this is for 10.164.2.100, which is a NAT address. So it checks ACLs and then does it's NATing, so the source and destination are now 172.26.14.15 and 172.26.14.36
Server gets the packet and sends a reply.
Firewall sees the reply, and translates the source and destinations back to 10.164.2.100/10.75.34.151
Firewall sees the outbound traffic matching a VPN rule, builds the tunnel to 10.164.2.30, and ships the encapsulated packet along.
The .100 address is NAT'd for those on the outside of the ASA, not for those on the other side of the WAN. Clients on the 10.75.34.0/24 subnet see the actual network address, 10.164.2.100. If you set up a VPN tunnel between these subnets I don't see the need for an additional NAT.
If there is any way to create a new subnet between the router and the ASA, I still think that is your best bet.
If you need to make things work as they are, there is a command on the ASA that allows you to send traffic out the same interface as it was received.
same-security-traffic permit intra-interface
However, this will not solve the issue of getting the devices on the 10.164.2.0/24 subnet to send their traffic to the ASA when they want to reach the 10.75.34.0/24 subnet. They will be sending traffic in the opposite direction to reach this subnet via the VPN tunnel as they do now.
The ASA may not have as much routing information as the router so you may need to configure static routes or dynamic routing on the ASA to make this work.
Sorry, you still don't understand that there is no DEVICE at 10.164.2.100. The actual DEVICE is on the "outside" network and it's NATed to the inside network.
More explicitly, the "inside" and "outside" networks here refer to the security levels of the interfaces, but EVERY bit of traffic through the firewall in either direction is NATed.
This is done so that the two sides don't really know each other exists. Each side has local addresses that represent physical devices on the other side. In this case, the web server at 172.26.14.36 is represented to the "inside" nets as 10.164.2.100. If you shut down the firewall, there would be nothing to respond to 10.164.2.100.
Sorry Tim, I see now that your diagram was meant to illustrate that .100 is a virtual device associated with the actual 172.26.14.36 outside host.
I believe your design will work using the .100 address in your IPSEC interesting traffic ACL. VPN only cares that you are using the source and destination addresses that correspond to your IPSEC interesting traffic ACL, whether or not they really exist. The static NAT should then translate the decrypted traffic destined for .100 to the .36 outside address. The reverse should happen for traffic returning from the .36 address.
If there are any real host devices on the 10.164.2.96 subnet they should point to the ASA instead of the router as their default gateway in order to traverse the VPN tunnel, and I believe you would also need the same-security-traffic permit intra-interface command to allow LAN traffic and VPN traffic through the same interface.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...