Cisco 1811, Dual WAN, IPSec Passthru only works through 1 WAN

We have a new 1811 router.  We're using fa0 and fa1 for 2 isps. Behind the 1811 is a 5510, in which we have our IPSEC VPN services, firewall rules, etc.  The 5510 has our LAN, Internal wifi, External wifi, and our IP phone system.  We worked out a great config for the 5510 and that has been working for months. We added the 1811after we discovered that the 5510 would not let us have a Dual WAN configuration.

Problem: The 1811 is in front of the 5510 and works fine for everything, except that incoming IPSEC pass thru only works on one of the WAN ports.

I've got 2 "ip nat inside source static" entries that I use to simply nat everything that comes into the 1811 to go to the 5510.  The 1811 filters nothing, we leave that the the 5510. We have a very simple configuration, I think.  And I've traced the probem (or the symptom) the details follow:

The public IPs shown here are ficticious for security purposes.

ISP1:
DSL
The 1811 is doing PPPOE
Static public IP 1.1.1.1
Interface FastEthernet0 (through Dialer1 / pppoe)
ip nat outside

ISP2:
DSL
The modem is doing PPPOE (not the 1811)
Static public IP 2.2.2.2
Interface FastEthernet1
ip nat outside

FastEthernet9 goes to 5510 over Vlan1
192.168.20.15/24
ip nat inside

The 5510 is set to IP 192.168.20.14.

We use Cisco's VPN Client on various PC's external to our office.  It works fine when connecting to ISP1 (1.1.1.1).  IPSEC passthru works fine.  It fails for ISP2 (2.2.2.2).  It won't accomplish the inital handshake, nor ask the user for their password. (We use a preshared key along with user authentication from active directory).  Here is why:

A user outside that has IP 99.99.99.99 trys to initiate a VPN connection to 2.2.2.2:

First I see this:
show ip nat trans
udp 2.2.2.2:500   192.168.20.14:500   99.99.99.99:37266 99.99.99.99:37266

Then a second later I see this:
show ip nat trans
udp 2.2.2.2:500   192.168.20.14:500   99.99.99.99:37266 99.99.99.99:37266
udp 1.1.1.1:500   192.168.20.14:500   99.99.99.99:37266 99.99.99.99:37266

So, bascially the issue is that the 1811 creates a translation back to ISP1 instead of where it originally came from.  The 5510 is responding perfectly, but the 1811 passes it back to the wrong ISP.

I've tried variations on the configuration, with and without route-maps on the nat, and other dumb ideas.

I've included the entire config of the 1811 (sanitized).

Thanks,
Kevin
Using 3470 out of 196600 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname router
!
boot-start-marker
boot-end-marker
!
logging buffered 51200 warnings
!
no aaa new-model
!
resource policy
!
!
!
ip cef
!
!
no ip domain lookup
ip domain name xxxxx
ip inspect name gen ipsec-msft
ip inspect name gen isakmp
!
!
crypto pki trustpoint TP-self-signed-3342582591
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-3342582591
 revocation-check none
 rsakeypair TP-self-signed-3342582591
!
!
crypto pki certificate chain TP-self-signed-3342582591
 certificate self-signed 01 nvram:IOS-Self-Sig#3102.cer
username cisco privilege 15 secret 5 xxxxxxxx
username admin privilege 15 secret 5 xxxxxxxxxx
!
! 
!
!
!
!
interface FastEthernet0
 no ip address
 ip access-group 100 in
 ip access-group 100 out
 ip nat outside
 ip inspect gen in
 ip inspect gen out
 ip virtual-reassembly
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
!
interface FastEthernet1
 ip address 2.2.2.2 255.255.255.252
 ip access-group 100 in
 ip access-group 100 out
 ip nat outside
 ip inspect gen in
 ip inspect gen out
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
!
interface FastEthernet5
!
interface FastEthernet6
!
interface FastEthernet7
!
interface FastEthernet8
!
interface FastEthernet9
!
interface Vlan1
 description Router Config Access
 ip address 192.168.20.15 255.255.255.0
 ip access-group 100 in
 ip access-group 100 out
 ip nat inside
 ip virtual-reassembly
 ip tcp adjust-mss 1452
!
interface Async1
 no ip address
 encapsulation slip
!
interface Dialer1
 description iphouse connection
 ip address negotiated
 ip access-group 100 in
 ip access-group 100 out
 ip mtu 1452
 ip nat outside
 ip inspect gen in
 ip inspect gen out
 ip virtual-reassembly
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication pap callin
 ppp pap sent-username xxxxxxxxxx password 0 xxxxxxxxxxxxx
!
ip route 0.0.0.0 0.0.0.0 FastEthernet1 10
ip route 0.0.0.0 0.0.0.0 Dialer1 10
!
!
ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip nat inside source route-map dsl1 interface Dialer1 overload
ip nat inside source route-map dsl2 interface FastEthernet1 overload
ip nat inside source static 192.168.20.14 2.2.2.2 route-map dsl2 extendable
ip nat inside source static 192.168.20.14 1.1.1.1.1 route-map dsl1 extendable
!
access-list 1 permit 192.168.20.0 0.0.0.255
access-list 2 permit 192.168.20.0 0.0.0.255
access-list 23 permit 10.10.10.0 0.0.0.7
access-list 23 permit 192.168.20.0 0.0.0.255
access-list 100 permit ip any any
no cdp run
!
!
!
route-map dsl2 permit 10
 match ip address 1
 match interface FastEthernet1
!
route-map dsl1 permit 10
 match ip address 1
 match interface Dialer1
!
!
!
!
control-plane
!
banner exec ^C
^C
banner login ^C
^C
!
line con 0
 login local
line 1
 modem InOut
 stopbits 1
 speed 115200
 flowcontrol hardware
line aux 0
line vty 0 4
 access-class 23 in
 privilege level 15
 login local
 transport input telnet ssh
line vty 5 15
 access-class 23 in
 privilege level 15
 login local
 transport input telnet ssh
!
!
webvpn context Default_context
 ssl authenticate verify all
 !
 no inservice
!
end
 
router#

Open in new window

LVL 12
kevin_uAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

nasirshCommented:
Try forwarding your port to the ASA rather then the route-map..The command will be like
no access-list 1
access-list 1 permit ip any any

ip nat inside source static tcp 192.168.20.14 1723 1.1.1.1 1723 extendable
ip nat inside source static tcp 192.168.20.14 1723 2.2.2.2 1723 extendable


By this method vpn traffic coming from the 1.1.1.1 and 2.2.2.2 respectively will be forwarded to the ASA.
Hope this helps
0
kevin_uAuthor Commented:
Its not PPTP its IPSEC.

UDP port 500 and protocol esp.
I tried forwarding those too, with the same issue.

0
asavenerCommented:
The problem is that IPSec uses two one-way UDP connections instead of a single two-way TCP connection.

You have one inbound UDP connection on port 500, and the ASA makes an outbound UDP connection on port 500, which hits your NAT rules and gets NAT'd out ISP1.

You can use route maps so that if ISP1 fails, the router will start to send traffic out ISP2, but I don't know of a way to load-balance IPSec between the ISPs, or to get the 1811 to recognize which interface the traffic originally entered.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Challenges in Government Cyber Security

Has cyber security been a challenge in your government organization? Are you looking to improve your government's network security? Learn more about how to improve your government organization's security by viewing our on-demand webinar!

asavenerCommented:
I checked on multiple context mode for the ASA, but it does not support VPNs in multiple context mode.
0
kevin_uAuthor Commented:
I suspected there might not be a solution, but I wanted an expert to confirm it.  

It would work if we moved the vpn enpoints to the 1811 I assume.  I'm going to have to see how many it supports.  I don't like moving them because now everything is admin'ed one place.
0
asavenerCommented:
The problem there will be routing.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Routers

From novice to tech pro — start learning today.