2

I've been trying to fix this myself but I'm afraid I can't.

I've tried basically every tutorial already, but it still doesn't work.

Can someone here write a tutorial on how to get PPPoE working with a NAT and internal DHCP?

All the information I got was the IP, Netmask PPP encapsulation (pap) and my username and password.

I have a cable that goes straight from the wall to the FastEthernet 4 port (WAN) in the Cisco 881W. My computer is connected through a console cable with Serial.

The IP is supposed to be 185.187.---.254 and the netmask is supposed to be 255.255.255.255

Current configuration : 2440 bytes

version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption

hostname Router

boot-start-marker
boot-end-marker

logging message-counter syslog

no aaa new-model
service-module wlan-ap 0 bootimage autonomous


ip source-route


ip cef
no ipv6 cef


multilink bundle-name authenticated
vpdn enable

vpdn-group 1
 request-dialin
  protocol pppoe

license boot module c880-data level advipservices




archive
 log config
  hidekeys





interface FastEthernet0
 pppoe enable group global
 pppoe-client dial-pool-number 1

interface FastEthernet1

interface FastEthernet2

interface FastEthernet3

interface FastEthernet4
 description Physical WAN Interface
 bandwidth inherit
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip flow ingress
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
 hold-queue 224 in

interface wlan-ap0
 description Service module interface to manage the embedded AP
 no ip address
 shutdown
 arp timeout 0

interface Wlan-GigabitEthernet0
 description Internal switch interface connecting to the embedded AP

interface Vlan1
 no ip address
 ip nat inside
 ip virtual-reassembly

interface Dialer0
 ip address negotiated
 ip verify unicast reverse-path
 no ip redirects
 no ip unreachables
 ip directed-broadcast
 no ip proxy-arp
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly
 encapsulation ppp
 ip tcp adjust-mss 1400
 load-interval 30
 dialer pool 1
 dialer-group 1
 ppp authentication pap callin
 ppp pap sent-username --- password 0 ---
 ppp ipcp dns request accept
 ppp ipcp route default
 ppp ipcp address accept

ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer0
no ip http server
no ip http secure-server


ip nat pool pool1 192.168.1.0 192.168.2.0 netmask 255.255.252.0
ip nat inside source list 1 interface Dialer0 overload
ip nat inside source list 100 interface Dialer0 overload
ip nat outside source list 1 interface FastEthernet0

access-list 1 permit 0.0.0.0 255.255.255.0
access-list 100 permit ip 192.168.0.0 0.0.0.255 any
dialer-list 1 protocol ip permit





control-plane


line con 0
 no modem enable
line aux 0
line 2
 no activation-character
 no exec
 transport preferred none
 transport input all
line vty 0 4
 login

scheduler max-task-time 5000
end

Router#
3

Thanks, I think I get the picture.

Oh, and while we're at it, stay away from "1" in lists, groups etc. It's an unnecessary obstacle for the novice, because - while technically correct and working perfectly - it does not help to see what belongs to what. So I'll be using different numbers (some go up to 128)

A full PPPoE, NAT, DHCP setup needs these things:

1. dialer-list & dialer-group

dialer-list defines what kind of traffic can trigger the dialer interface into action (remember, those were used back in the heyday of dial-on-demand routing and ISDN, where you would want to prevent all costly channels from being up all the time).

You can define criteria that explicitely define which traffic patterns are considered "interesting" - again, remember that the historic router had to be able to dial out via e.g. ISDN for one given range of destination IPs, while for another IP range a modem connection was to be used. To set these criteria, (numbered) access list were usually used.

That would look like this:

router(config)#dialer-list 124 protocol ip list ?
  <1-199>      IP access list
  <1300-2699>  IP expanded access list

However in your case, the following will do nicely, as we consider any IP traffic interesting.

dialer-list 124 protocol ip permit

and under the Dialer Interface, we reference that dialer-list:

interface dialer 0
 [...]
 dialer-group 124
 [...]

2. PPPoE Config: dialer pool and interface

Of course, the interface that is going to talk PPPoE needs to be configured. I think you got that one nicely. Howewer, again I suggest to stay away from the "1".

interface fastEthernet4
 no ip address
 pppoe enable group global
 pppoe-client dial-pool-number 122

Interface FastEthernet0 on a 881 is not a PPPoE interface. Please be sure to remove all PPPoE related config from there.

On the dialer interface, you need to assign the interface to a dialer pool (Remember, the historic routers sometimes had many dialer interfaces and many different dialing-capable interfaces of different nature to choose from, hence the dialer-pool.)

interface dialer 0
 [...]
 dialer-pool 122
 [...]

3. PPPoE authentication/negotiation

That one is most often defined by the service provider

interface Dialer 0
 ip address negotiated
 [...]
 ppp authentication pap callin 
 ppp pap sent-username <USERNAME> password 0 <PASSWORD> 
 ppp ipcp dns request accept 
 ppp ipcp route default 
 ppp ipcp address accept

These bits configure the dialer interface, to ...

  • not have a predefined IP address, but to negotiate it (using IPCP).
  • use PAP as authentication mechanism (alternative: CHAP)
  • send and (remember that with PAP, these are sent in cleartext!)
  • request DNS server information via PPP-IPCP
  • request to learn the default route via PPP-IPCP
  • request to obtain an IP address

4. Default Route

There needs to be a (default) route pointing through the dialer interface; I think you got that right:

ip route 0.0.0.0 0.0.0.0 Dialer0

I however suggest this (adding a floating default with admin distance 10)

ip route 0.0.0.0 0.0.0.0 Dialer0 10

The ppp ipcp route default from the dialer0 interface will install a route with administrative distance 1, overriding the above one while the PPPoE session is up.

6. LAN interface, DNS and DHCP

The 881 has an integrated 4-port switch which you need to treat as such. You cannot assign IP adresses to its individual interfaces, but you need a VLAN and an SVI ("interface vlan") to go along with it.

In this case, we'll use 192.168.10.0 and VLAN10 as internal network. Adapt accordingly to fit your network situation.

vlan 10
 name INSIDE_VLAN

interface FastEthernet0
 description LAN PORT
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast

interface FastEthernet1
 description LAN PORT
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast

interface FastEthernet2
 description LAN PORT
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast

interface FastEthernet3
 description LAN PORT
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast

interface vlan 10
 ip address 192.168.10.1 255.255.255.0

Then you'll need some DHCP and DNS bits to configure. We want our router to act as DNS proxy for the clients (forwarding all DNS requests to the DNS server we configure manually, or the ones learnt via PPP-IPCP, see above)

We want our DHCP pool to go from 192.168.10.64 to 192.168.10.127, and to hand out some proper information to our clients and set the DHCP lease time to 1 day, 0 hours, 0 minutes.

ip dns server
ip dhcp excluded-address 192.168.10.1 192.168.10.63
ip dhcp excluded-address 192.168.10.128 192.168.10.255

ip dhcp pool MYVLAN10-POOL
 network 192.168.10.0 255.255.255.0
 default-router 192.168.10.1
 dns-server 192.168.10.1
 lease 1 0 0

Of course, if you want your LAN clients to query some other DNS server (like an internal one, or Google's 8.8.8.8 and 8.8.4.4, you can add these to the DHCP pool config). In that case, I suggest to remove the ip dns server and the ppp ipcp dns config bits.

7. NATty things

To make NAT work, you need:

  • an access list that defines which traffic is allowed into NAT (usually your entire internal subnet)
  • an "inside" interface
  • an "outside" interface
  • a NAT rule that defines how things are NATted.

The example will assume that you will want to NAT-overload (a.k.a. "hiding NAT" or "IP masquerading") to the current (public) IP address of the Dialer interface.

It will use a named access list - please note that ACLs use wildcard masks, not subnet masks (binary inversion). I think here was the major config error in your example.

ip access list standard ACLv4_NATOVERLOAD
 permit ip 192.168.10.0 0.0.0.255

interface dialer0
 ip nat outside

interface vlan 10
 ip nat inside

ip nat inside source list ACLv4_NATOVERLOAD interface Dialer0 overload 

8. other clever bits to have

There's some clever config bits here and there, and I'll comment them here

interface dialer 0 
 ip mtu 1492

That is a must-have when running PPPoE, each IP packet on interface FastEthernet4 will get an additional PPPoE header of 8 bytes, so you want to reduce MTU for interface dialer 0.

interface dialer 0
 ip tcp adjust-mss 1452

That's also a good idea, although the 1400 you had might be a bit overdone. MSS is usually MTU-40, so 1452 might be good enough.

interface FastEthernet4
 no ip proxy-arp

interface dialer 0 
 no ip redirects 
 ip unreachables 
 no ip proxy-arp

interface vlan 10
 ip verify unicast reverse-path 
 ip unreachables 
 no ip proxy-arp

proxy-arp is a networking black witch I will personally burn at the stake whenever I come across her. Her magic is only needed in dark corner cases - leave it disabled, unless you really, really, need it.

However, ip unreachables are a blessing when it comes to reduced-MTU links as in your case. They make sure that the router can inform a host to send smaller packets - especially for UDP applications; TCP is taken care of by ip tcp adjust-mss. Unfortunately, not all hosts will respect or understand these "packet too big" messages, but that's their problem.

ip verify unicast reverse-path is good best practice, it prevents ip source address spoofing, by allowing only those source address ranges (incoming) on an interface for which a route exits in the reverse direction through that same interface. That makes it harder for your internal systems to be part of a bot army working with spoofed source adresses.

| improve this answer | |
  • @RK you should consider upvoting Marc answer, it deserves it, and this is how Stack Exchange works. – JFL Sep 13 '17 at 13:37
  • Really? weird... – JFL Sep 13 '17 at 14:20
  • Glad to hear it all worked out. Depending on your given network scenario, you may want to look further into CBAC (Context Based Access Control, a bit legacy style, simpler to configure) or ZBFW (Zone Based FireWall, modern style, highly flexible, but more complex to set up) to enhance your router's security stance or improve application support through NAT (protocol inspection for SIP and the likes). This will of course put some load on the router's CPU, be sure to balance features vs performance. – Marc 'netztier' Luethi Sep 14 '17 at 20:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy