04-05-2016 01:05 PM - edited 03-05-2019 03:43 AM
I have a centurylink dsl modem in bridge mode connected to my cisco2821 at my home office. Everything was working fine while I was using dhcp on WAN interface. Problem started when I decided that I needed a static IP. Primary reason was for security. I wanted to lock down access to my corporate routers with ACLs but still wanted to manage from home... plus gre tunnel for easy access. The static IP given to me by centurylink was 64.91.6.171 255.255.255.255 which seemed really weird to me due to the subnet mask, but apparently is valid and used in situations with point-to-point and pppoe. My problem is that I cannot assign that IP/Netmask to my dialer interface because it says "Bad Netmask /32". After some research, I created a loopback and assigned the given address with no problem. Then changed the dialer interface from "ip address negotiated" to "ip unnumbered lo1" which accomplished getting the desired IP onto the dialer interface, but I could not pass traffic. Below is a copy of my working config while using dhcp. What am I missing? Didn't think it would be this hard to add a static IP.
----------------------------------------------------------------------------------------
version 15.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname TFD-Router
!
boot-start-marker
boot-end-marker
!
!
enable secret 5 $1$9Osk$PoVnOmnac8UFi6fT0ve610
!
no aaa new-model
!
!
dot11 syslog
ip source-route
!
!
ip cef
!
ip dhcp excluded-address 192.168.1.1 192.168.1.99
ip dhcp excluded-address 192.168.1.200 192.168.1.255
!
ip dhcp pool Primary_DHCP_Pool
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 8.8.8.8 8.8.4.4
!
!
ip domain name deangelo.local
ip name-server 8.8.8.8
ip name-server 8.8.4.4
no ipv6 cef
!
multilink bundle-name authenticated
!
vpdn enable
!
vpdn-group 1
!
voice-card 0
!
crypto pki token default removal timeout 0
!
!
!
!
license udi pid CISCO2821 sn FTX1126A47J
!
redundancy
!
interface Tunnel1
ip address 172.16.1.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source 174.xxxxxxxx
tunnel destination 208.xxxxxxxx
!
interface GigabitEthernet0/0
no ip address
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
no cdp enable
!
interface GigabitEthernet0/1
ip address 192.168.1.254 255.255.255.0
ip nat inside
ip virtual-reassembly in
glbp 1 ip 192.168.1.1
glbp 1 priority 110
glbp 1 preempt
duplex auto
speed auto
!
interface Async0/0/0
no ip address
encapsulation slip
!
interface Dialer1
ip address negotiated
no ip unreachables
ip mtu 1492
ip nat outside
ip virtual-reassembly in
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname CTLxxxxxx
ppp chap password 0 xxxxxxx
ppp pap sent-username CTLxxxxxx password 0 xxxxxxx
ppp ipcp route default
no cdp enable
!
router ospf 1
network 10.0.0.1 0.0.0.0 area 0
network 172.16.1.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 0
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip nat inside source list NAT_INSIDE_ADDRESSES interface Dialer1 overload
!
ip access-list extended NAT_INSIDE_ADDRESSES
permit ip 192.168.1.0 0.0.0.255 any
!
dialer-list 1 protocol ip permit
!
line con 0
exec-timeout 0 0
logging synchronous
line aux 0
line 0/0/0
stopbits 1
speed 115200
flowcontrol hardware
line vty 0 4
logging synchronous
login local
transport input ssh
line vty 5 15
logging synchronous
login local
transport input ssh
!
scheduler allocate 20000 1000
end
04-05-2016 01:20 PM
Feedback forum is dedicated to other topics. Moved to more appropriate community.
04-05-2016 08:41 PM
Hi,
It is possible that this static IP address is meant by your ISP to be used on a different interface of your router, or in a NAT configuration, but the Dialer interface should continue using an automatically assigned IP address. In other words, it is possible that your ISP only routes this IP address to you but does not expect you to use this IP address for the PPPoE link.
There is a quick test for this: Leave your Dialer interface configured with ip address negotiated and assign the static IP address to a loopback interface like you did when you experimented with IP Unnmbered. Then try pinging the static IP address from a host out in the internet, or alternatively, from the router, try pinging an external host using the source keyword - if my theory is correct, the ping will work:
ping 8.8.8.8 source loopback0
Best regards,
Peter
04-06-2016 01:20 PM
So when I got home yesterday, I took my dsl out of bridge mode so I could remove the Cisco from the mix. The connection would not work with the static. After working with Centurylink for almost two hours, they found a provisioning problem with the IP they gave me (they didn't really give any details). After finally getting the connection to work through the dsl modem, I put the modem back into bridge mode and added the cisco back in. Now I can ping out from WAN IP which I could not do before. Still no luck from the LAN though - can ping WAN address from LAN but no further. To make things even weirder, the GRE tunnel to my office is up. From my home LAN I can get across the internet using the tunnel and access all my office resources (and access home from office) but nothing on the internet. That led me to believe I had a NAT problem so I removed all NAT configuration and then reprogrammed. Still no luck. One more piece of info - when I do "sh ip int br" it shows the static I programmed for both the dialer interface and the loopback. When I do an "sh ip route" it shows my static IP for the loopback, but a different ip for my dialer. The address that shows up for the dialer is the same as the next hop address for the default route that ipcp brought in. Something is really weird here! I won't repost my whole config again, but here are the pertinent parts:
!
interface Loopback1
ip address 64.xx.x.xxx 255.255.255.255
!
interface Tunnel1
ip address 172.16.1.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source 64.xx.x.xxx
tunnel destination 208.xx.xxx.xx
!
interface GigabitEthernet0/0
no ip address
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
no cdp enable
!
interface GigabitEthernet0/1
ip address 192.168.1.254 255.255.255.0
ip nat inside
ip virtual-reassembly in
glbp 1 ip 192.168.1.1
glbp 1 priority 110
glbp 1 preempt
duplex auto
speed auto
!
interface Dialer1
ip unnumbered Loopback1
no ip unreachables
ip mtu 1492
ip nat outside
ip virtual-reassembly in
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname xxxxx
ppp chap password 0 xxxxx
ppp pap sent-username xxxxx password 0 xxxxx
ppp ipcp dns request accept
ppp ipcp route default
ppp ipcp address accept
no cdp enable
!
ip nat inside source list NAT_INSIDE_ADDRESSES interface Dialer1 overload
ip route 192.168.8.0 255.255.248.0 172.16.1.2
ip route 192.168.16.0 255.255.255.0 172.16.1.2
ip route 192.168.18.0 255.255.255.0 172.16.1.2
!
ip access-list extended NAT_INSIDE_ADDRESSES
permit ip 192.168.1.0 0.0.0.255 any
04-06-2016 05:38 PM
It looks like the problem is definitely NAT related. Not sure where to go from here...
Here is some debug output.
*Apr 7 00:59:58.651: mapping pointer available mapping:0
*Apr 7 00:59:58.655: NAT*: Can't create new inside entry - forced_punt_flags: 0
*Apr 7 00:59:58.655: mapping pointer available mapping:0
*Apr 7 00:59:58.655: NAT: translation failed (A), dropping packet s=192.168.1.101 d=8.8.8.8
*Apr 7 00:59:59.311: mapping pointer available mapping:0
*Apr 7 00:59:59.311: NAT*: Can't create new inside entry - forced_punt_flags: 0
*Apr 7 00:59:59.311: mapping pointer available mapping:0
*Apr 7 00:59:59.311: NAT*: Can't create new inside entry - forced_punt_flags: 0
*Apr 7 00:59:59.311: mapping pointer available mapping:0
04-08-2016 08:52 AM
I finally got it working last night off of some articles I found online. I tried altering my ACLs at first, but that did not help. First I went simpler with a standard ACL and when that didn't work I created an extended that allowed NAT but denied GRE tunnel traffic so ACL looks like this:
access-list 105 deny ip 192.168.1.0 0.0.0.255 192.168.8.0 0.0.0.255
access-list 105 deny ip 192.168.1.0 0.0.0.255 192.168.16.0 0.0.0.255
access-list 105 deny ip 192.168.1.0 0.0.0.255 192.168.18.0 0.0.0.255
access-list 105 deny ip 192.168.1.0 0.0.0.255 172.16.1.0 0.0.0.255
access-list 105 permit ip 192.168.1.0 0.0.0.255 any
Unfortunately neither alteration of the ACL helped. The solution wound up being that I had to leave the "ip nat outside" on the dialer interface but change my nat command from:
ip nat inside source list 105 interface Dialer1 overload
ip nat inside source list 105 interface Loopback1 overload
I had read people saying that you would never put this command on the loopback but I guess since the loopback is where the actual IP resides then it is necessary. Thanks for your help.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide