Odd DSL problem - IP Negotiated and Static Address Weirdness

Unanswered Question
Jan 23rd, 2008
User Badges:

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


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

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

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 Dialer1


access-list 101 permit gre host x.x.x.x host z.z.z.z



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.5 (2 ratings)
irisrios Tue, 01/29/2008 - 11:19
User Badges:
  • Silver, 250 points or more

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.


paolo bevilacqua Tue, 01/29/2008 - 13:22
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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 ?

cybrsage Tue, 01/29/2008 - 21:40
User Badges:

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.


This Discussion