Odd DSL problem - IP Negotiated and Static Address Weirdness

cybrsage · ‎01-23-2008

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!

irisrios · ‎01-29-2008

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

paolo bevilacqua · ‎01-29-2008

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 · ‎01-29-2008

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.