01-23-2008 12:16 PM - edited 03-03-2019 08:23 PM
I have never seen anything like this before. I am doing VPN over DSL.
Cisco 1811 router to a Netopia 3347 modem (setup in bridged mode). Set of 8 static addresses for the 1811.
When setup with a static address, the interface bounced up and down, like this:
Jan 23 15:04:22 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
Jan 23 15:04:54 EST: %DIALER-6-UNBIND: Interface Vi1 unbound from profile Di1
Jan 23 15:04:54 EST: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
Jan 23 15:04:55 EST: %LINEPROTO-5-PDOWN: Line protocol on Interface Virtual-Access1, changed state to down
Jan 23 15:05:16 EST: %DIALER-6-BIND: Interface Vi1 bound to profile Di1
Jan 23 15:05:16 EST: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Jan 23 15:05:17 EST: %LINEPROTO-5-PDOWN: Line protocol on Interface Virtual-ccess1, changed state to up
If I setup ip address negotiated the interface comes up, but my VPN tunnels do not come up (naturally, since the IP address is now incorrect).
If I then change the address to my static address, the tunnels come up and everything is honkey dorey.
As a paranoia check, I rebooted the router. I am then back where I started, with the interface bouncing up and down.
If I then change to ip address negotiated, it connects, and I can repeat the cycle ad nauseum.
Here is the relevant portions of my config:
policy-map tunnel256
class class-default
shape average 256000
!
vpdn enable
!
vpdn-group dsl
request-dialin
protocol pppoe
!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 5
lifetime 7200
crypto isakmp key somekey address zzz.zzz.zzz.zzz
!
crypto map vpn 9000 ipsec-isakmp
set peer zzz.zzz.zzz.zzz
set transform-set secure
match address 101
!
interface Tunnel9000
bandwidth 256
ip address yyy.yyy.yyy.yyy 255.255.255.252
ip mtu 1420
delay 2000
cdp enable
tunnel source Dialer1
tunnel destination zzz.zzz.zzz.zzz
service-policy output tunnel256
!
interface FastEthernet0
description Outside interface
no ip address
ip mtu 1300
no ip route-cache cef
no ip route-cache
no ip mroute-cache
duplex auto
speed auto
pppoe enable
pppoe-client dial-pool-number 1
no cdp enable
arp timeout 300
!
interface Dialer1
ip address xxx.xxx.xxx.xxx 255.255.255.248
ip mtu 1300
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication pap chap callin
ppp chap hostname stuff
ppp chap password stuff
ppp pap sent-username stuff password stuff
ppp ipcp route default
crypto map vpn
!
ip route z.z.z.z 255.255.255.255 Dialer1
!
access-list 101 permit gre host x.x.x.x host z.z.z.z
!
HELP!
01-29-2008 11:19 AM
I think open port 10000 for NAT. The problem is the DSL router/modem doesn't handle PAT correctly. This problem has been seen in numerous different vendors SOHO DSL router/modems. The main problem is that these SOHO routers assign the same source port to each VPN client connection. In order for a router to properly implement PAT, it needs to assign each connection a different source port. This is especially important when using IPSec from a client to a server. But your configuration is looking fine.
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_configuration_example09186a008071a77c.shtml
01-29-2008 01:22 PM
That doesn;t apply, because the ADSL modem/router is set as bridge and doesn't do any NAT nor routing. It is a purely L2 device.
Wrt the question, which exact IOS are you running ?
01-29-2008 09:40 PM
Heh, actually forgot I posted this.
Update on the situation and the "fix".
After fighting through several levels of the service provider's support group, over the last few weeks, I found out the issue is with them giving out a block of addresses.
Apparently, their system cannot handle both the DSL modem being in bridge mode AND a block of addresses at the same time. This is something their sales group, their first two levels of support, and their field support staff do not know.
Once we found this out, I had them give me a single static address (all we needed). They assigned this to me via DHCP, and I get the same one each time.
Problem solved. The issue was the ISP, not the Cisco.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: