Solved: How can I accomplish this IPSec proxying/relaying/passthrough issue...?

CWF Netman · ‎08-09-2010

I have a situation where I'm needing to allow an IPSec client (Windows, software-based classic IPSec using ESP+AH+UDP) to be able to reach a site out over the public Internet. The problem is that the Windows workstation is nested three levels deep in internal networks away from the public Internet, and presently there is no direct NAT or any kind of direct routability to the public Internet at all.

From the Internet to this deep internal network, there exists this following path:

Raw Internet -> T1 line connected to C1721 router -> ASA5520 firewall -> C3845 router -> Internel LAN network #1 at location "A" using Catalyst switch infrastructure (this network is all RFC1918 privately addressed) -> Another C3845 router with extensive ACLs as an interior firewall -> Another different internal LAN network #2 using another Catalyst switch stack at location "B" with completely different RFC1918 private address scheme -> Windows PC at location "B" residing on this LAN that needs to be able to IPSec VPN to a site out on the public Internet.

How can I make this work when I'm legally prohibited from installing a directly-Internet-connected firewall directly to the interior LAN at location "B"...it's a law enforcement agency with strict connection rules... yet I'm being expected to make this deal work within the existing physical framework of the network architecture?

adhar · ‎08-23-2010

Need some more explanation. Can you separate the site a and site b more clearly and identify hosts from site "a' and hosts from "site b" which you want to reach. You can lable them as "host a" and "host b".

Now coming back to your question, even before you try to establish ipsec connectivity, your layer 3 has to be up.

It does not matter how many firewalls/nat rules it has to pass - but the layer 3 connectitivity has to be up.Advisable to open ping connectivity for testing to make it easy. If not then you will have to rely on captures/debugs at both ends to ensure you are sending/receiving the packets. When it is nat you need udp 500 and udp 4500 connectivity.

Hope this helps.

CWF Netman · ‎08-23-2010

I can ping the remote VPN server from the internal workstation at site B.

UDP ports 500 and 4500 access rules (both in and out) are in place in the ASA5520 for the workstation.

I've also enabled protocols 50 and 51 access rules, as well as NAT for that workstation.

The VPN software client is Nortel Contivity and so is the server it's trying to reach over the internet.

Site B is where the workstation resides. Site B is connected to Site A via a fiberoptic cable with Cisco 3845 routers at each end.

Site A is where the Internet connectivity exists for both Site A and Site B. The Cisco ASA 5520 firewall resides at Site A.

In other words, Site B gets its (natted) Internet thru Site A (and thru the pair of 3845 routers). Providing direct Internet routability to Site B is legally prohibited.

The workstation on Site B's internal LAN is trying to reach a Nortel Contivity VPN server out on the Internet somewhere (let's call that Site "C").

Site B's internal LAN is a private internal network with one set of RFC-1918 ip addresses.

Site A's internal LAN is a different internal network with a completely different set of RFC-1918 addresses.

The router-to-router subnet between Site A's 3845 router port and Site B's 3845 router port is yet a third different RFC-1918 address space.

Static routes are set up at both ends so that "normal" tcp/ip traffic flows between hosts on these two sites just fine.

The Cisco ASA 5520 at Site A has one interface directly routed to the public Internet ("Outside" interface), and another interface ("Inside" interface) on Site A's internal LAN. The ASA's "Management" interface is on a network of it's own, connected to a dedicated management workstation only.

Establishing a VPN client connection from a workstation on Site A's internal LAN to a host out somewhere on the public Internet works fine thru NAT on the ASA 5520.

Trying to VPN from a workstation on Site B's internal LAN, thru the two routers, then thru the ASA5520 to a host somewhere out on the public Internet is not working.

It's almost as if the ASA5520 cannot successfully perform NAT for other than icmp packets for a workstation that's statically routed two networks away from his "Inside" interface.

CWF Netman · ‎08-27-2010

I think I finally figured out why my ASA was not successfully passing the IPSec Client traffic out to the outside world.

The IPSec Client software was Nortel Contivity, and the problem had nothng to do with the client being two routed private networks away from and behind the ASA as I had originally suspected.

I was running the new 8.3 software on the ASA and it appears this new operating system is either completely incompatible with the legacy IPSec traffic generated by the Nortel Contivity Client, or possibly that something is horribly buggy with the manner, and sequence in which 8.3 is applying NAT and ACLs to the IPSec traffic trying to flow thru it to the outside world and the return traffic coming back to the client. The logs and debugs were not showing any useful clues or reason why it wasn't working.

I downgraded my ASA to 8.2.3 and re-created all my NAT and Access rules and like magic, everything started working correctly as expected.