We have a PIX at a remote data center and - in the event of an upstream routing issue or some issue beyond our control - we'd like to be able to VPN to an interface that is completely off of the "main" network. The problem is the default route is going out the "main" outside interface of the PIX and the traffic is apparently not allowed to return back to the VPN client.
eth0 "eth-outside" - 184.108.40.206
eth1 "eth-inside" - 192.168.0.1
eth3 "eth-backup" - 220.127.116.11
18.104.22.168 = Gateway
The only routing statement on the PIX is this. This is the route that all "normal" production traffic flows out/in:
route eth-outside 0.0.0.0 0.0.0.0 22.214.171.124 1
If the 126.96.36.199 network becomes inaccessible for whatever reason how can we VPN to the 188.8.131.52 network on the "backup" interface?
Note: I can get this to work if I know *where* the VPN client is coming from. Example: If the VPN client is connecting from 184.108.40.206 I can simply put in a route back out eth3 like this (assuming that 220.127.116.11 is the gateway for this network):
This does work but obviously it isn't optimal to know from where the VPN clients might be originating. Is there a way I can do this so the response from the PIX as well as traffic after the client is connected flows back out the interface that was used to connect in the first place?
You can configure backup route for the backup ISP in the event that the primary ISP is down. Basically what you would need to do is monitoring a specific ip address, and when that ip address is inaccessible, then the default gateway will failover to the backup ISP. And once the primary ISP is up and running, it will automatically fail back to the primary ISP. Is this something which you would like to implement?
Here is the sample configuration for your reference:
One thing I left out to keep the post less verbose was that we have 2 ISPs and are running BGP with our routers in front of the PIX pair. Our advertised network is the "primary" outside interface on the pix. We have non-advertised - from our perspective "non-bgp'ed" - blocks that we control as well. We were going to take an extra smaller block and just use it on that backup interface, skipping the routers entirely (in case there was an issue with the routers/config/etc) and going right out one of our ISPs gateways upstream.
I'll review that documentation but my concern is that the PIX would still "think" that the primary route outbound is available even though - for example - there was some nasty routing issue preventing us from getting in over our normal BGP advertised route.
In general I'm probably being peranoid as we already have another PIX that is accessible over a different network in that same data center. Once VPNed into that PIX it is possible to access the over over out-of-band methods. This other PIX was really dropped in for the purpose of the data center setup and we hadn't considered keeping in there permanently. Maybe we should....
That being said, thanks for the link- I will definitely check out that documentation and see if might help or point me in a slightly different direction/solution.
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...