Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

"No internet access" on Guest Wifi

We upgraded our router the other day, we made a backup as well as a txt copy of the config file for copying in various commands to the new router .

We have a Secure wifi for employees and a Guest wifi for visitors. We have a server doing the DHCP(10.27.131.8) for both the secure (10.27.131.0 network) and for the Guest (10.26.131.0 network). The Secure wifi is working as it should be - the Guest however is not. Visitors can connect and get a valid IP address from the 10.26.131.0 network but have no internet access. Everything else has stayed the same - no changes to the AP's.

Again we copied the config from the old to the new with a few minor changes but nothing that should effect the Guest wifi.

I did an ipconfig after connecting to the Guest Wifi and I can get a correct IP address 10.26.131.214, Default GW: 10.26.131.1.

 

I enclosed the config from my router is anybody could shed some light,

Thanks in advance.

 

Building configuration...
!
aaa new-model
!
!
aaa authentication login default line local
aaa authentication login vtymethod group tacacs+ line
aaa authentication login conmethod line
aaa authentication login httpmethod group tacacs+ local
aaa authentication enable default enable group tacacs+
aaa authentication ppp default none
aaa authorization config-commands
aaa authorization exec default local group tacacs+ none
aaa authorization commands 1 default group tacacs+ if-authenticated
aaa authorization commands 15 default group tacacs+ none
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting network default start-stop group tacacs+
aaa accounting system default start-stop group tacacs+
!
aaa session-id common
!
resource policy
!
ip subnet-zero
!
!
ip cef


no ip dhcp use vrf connected


ip dhcp excluded-address 10.26.131.1 10.26.131.100
!
ip dhcp pool guest
   network 10.26.131.0 255.255.255.0
   dns-server 208.67.222.222 208.67.220.220
   default-router 10.26.131.1
   domain-name guest.X.xxx

!
interface Tunnel3
 ip address 172.17.3.2 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source 12.xx.xx.xx
 tunnel destination 19x.xx.xx.xx
!
interface Tunnel55
 ip address 192.168.66.10 255.255.255.0
 ip accounting output-packets
 ip accounting access-violations
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source 12.xx.xx.xx
 tunnel destination 12.xx.xx.xx
!
interface FastEthernet0/0
 ip address 12.xx.xx.xx 255.255.255.248
 ip nat outside
 ip route-cache flow
 duplex auto
 speed auto
 service-policy output physical
!
interface FastEthernet0/1
 description CONNECTION TO SW3
 no ip address
 duplex auto
 speed auto
 service-policy output physical
!
interface FastEthernet0/1.1
 description LAN
 encapsulation dot1Q 1 native
 ip address 10.27.131.254 255.255.255.0
 ip flow ingress
 ip flow egress
 ip nat inside
 no snmp trap link-status
!
interface FastEthernet0/1.20
 description GUEST NETWORK
 encapsulation dot1Q 20
 ip address 10.26.131.1 255.255.255.0
 ip access-group 101 in
 ip helper-address 10.27.131.8
 no snmp trap link-status
!
interface FastEthernet0/1.200
 description Phone VLAN
 encapsulation dot1Q 200
 ip address 10.5.2.254 255.255.255.0
 no snmp trap link-status
!
interface Serial0/0/0
 no ip address
 shutdown
!
interface Serial0/2/0
 no ip address
 shutdown
!
interface Serial0/3/0
 no ip address
 shutdown
!
ip classless
ip route 0.0.0.0 0.0.0.0 12.xx.xx.xx
ip route 10.5.5.0 255.255.255.0 10.5.2.1
ip route 10.10.0.0 255.255.255.0 172.17.3.5
ip route 10.10.200.0 255.255.255.0 172.17.3.5
ip route 10.25.131.0 255.255.255.0 192.168.66.20
ip route 10.27.129.0 255.255.255.0 172.17.3.5
ip route 10.27.130.0 255.255.255.0 172.17.3.5
ip route 140.xx.xx.xx 255.255.0.0 172.17.3.5
ip route 192.168.2.0 255.255.254.0 172.17.3.5
ip route 192.168.99.0 255.255.255.0 172.17.3.5
!
!
ip http server
ip http authentication local
ip http secure-server
ip nat inside source list 2 interface FastEthernet0/0 overload
!
access-list 2 permit 10.27.131.0 0.0.0.255
access-list 2 permit 10.25.131.0 0.0.0.255
access-list 2 permit 192.168.66.0 0.0.0.255
access-list 2 permit 10.14.0.0 0.0.0.255
access-list 2 permit 10.5.5.0 0.0.0.255
access-list 2 permit 10.5.2.0 0.0.0.255
access-list 5 deny   10.27.131.123
access-list 5 permit 192.168.2.0 0.0.0.255
access-list 5 permit 10.27.131.0 0.0.0.255
access-list 5 permit any
access-list 101 permit tcp any host 10.27.131.8 eq 67
access-list 101 permit udp any host 10.27.131.8 eq bootps
access-list 101 permit ip 10.26.131.0 0.0.0.255 host 10.14.0.6
access-list 101 deny   ip 10.26.131.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 101 deny   ip 10.26.131.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 101 deny   ip 10.26.131.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 101 deny   icmp 10.26.131.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 101 deny   icmp 10.26.131.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 101 deny   icmp 10.26.131.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 101 permit ip 10.26.131.0 0.0.0.255 any
access-list 102 permit icmp 10.25.131.0 0.0.0.255 any
access-list 102 permit ip 192.168.66.0 0.0.0.255 any
access-list 102 permit ip 10.25.131.0 0.0.0.255 any
access-list 102 permit ip 10.27.131.0 0.0.0.255 any
!
 

 

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Hi,

Hi,

I also apologize for my late answer.

I appears your ACL 101 that filters traffic entering the Fa0/1.20 is not correctly written to allow DHCP requests to be processed by the router. The attempt has been made - but it is not correct. In particular, check out the second entry in the ACL 101:

access-list 101 permit udp any host 10.27.131.8 eq bootps

It allows all DHCP messages that are already targeted to 10.27.131.8, the DHCP server. However, such targeted DHCP messages may be used by clients only after they know who the DHCP server is in the first place. Until then, the requests are targeted to 255.255.255.255 and sourced from 0.0.0.0. Such packets are not allowed by any entry in the ACL 101 and are therefore dropped even before the DHCP Relay Agent can process them. That would explain why your clients actually cannot obtain IP address via DHCP in VLAN 20.

We need to add the following entry immediately before or after the existing second entry in the ACL 101:

access-list 101 permit udp any host 255.255.255.255 eq bootps

You may accomplish this by the following sequence of commands directly pasted into the global configuration:

ip access-list resequence 101 10 10
ip access-list extended 101
15 permit udp any host 255.255.255.255 eq bootps
end

The first line will cause the individual entries of the ACL 101 to be internally numbered, starting with the sequence number 10 and incrementing by 10 for each subsequent entry. The second line enters the ACL 101, treating it as a named ACL, allowing us to use the extended editing features. Finally, the third line starting with the sequence number 15 will cause the entry to be added between the existing first (seq no 10) and second (seq no 20) entry. It must be entered including the sequence number, otherwise the line will be added at the end of the ACL.

Would you mind trying out this modification? The former corrections with the NAT I have described earlier must be applied as well.

Best regards,
Peter

 

10 REPLIES
Cisco Employee

Hi,After checking your

Hi,

After checking your configuration briefly, these appear to be the major problems with it:

  • Your Fa0/1.20 subinterface is missing the ip nat inside command
  • Your ACL 2 is missing the access-list 2 permit 10.26.131.0 0.0.0.255 entry

Can you try adding these to your configuration and retest the guest connectivity?

Best regards,
Peter

 

New Member

Peter,I added both of those

Peter,

I added both of those lines to the config but I get the same result "Connected  - No internet access"

DHCP is working correctly.

Cisco Employee

Hi,I see. That message is a

Hi,

I see. That message is a Windows message, right? It doesn't really say what the problem is...

Can we try tracerouting from a guest to some public IP address? Can you try running, e.g.:

tracert -d 158.193.152.2

on a guest machine and let us know the results? Thanks!

Best regards,
Peter

New Member

Peter, So doing an ipconfig

Peter,

 

So doing an ipconfig comes back with the 169.254 address. I didn't get a chance to run your command yesterday but previous troubleshooting lik trying to ping the default GW 10.26.131.1 failed(timed out) when I had an IP address of 10.26.131.214.

I dont understand why the DHCP range is now now working?

New Member

Sorry,We had a more important

Sorry,

We had a more important issue come up the past week.

Getting back to this, I have included 2 screenshots - the first shows successful pings to the GW for the Guest 10.26.131.1 and the second shows ipconfig - not getting an IP address for the wireless connection.

I have removed the DHCP pool Guest from the router, the only thing relating to the Guest is on the interface pointing at the DHCP server 10.27.131.8

interface FastEthernet0/1.20
 description GUEST NETWORK
 encapsulation dot1Q 20
 ip address 10.26.131.1 255.255.255.0
 ip access-group 101 in
 ip helper-address 10.27.131.8

Cisco Employee

Hi,

Hi,

I also apologize for my late answer.

I appears your ACL 101 that filters traffic entering the Fa0/1.20 is not correctly written to allow DHCP requests to be processed by the router. The attempt has been made - but it is not correct. In particular, check out the second entry in the ACL 101:

access-list 101 permit udp any host 10.27.131.8 eq bootps

It allows all DHCP messages that are already targeted to 10.27.131.8, the DHCP server. However, such targeted DHCP messages may be used by clients only after they know who the DHCP server is in the first place. Until then, the requests are targeted to 255.255.255.255 and sourced from 0.0.0.0. Such packets are not allowed by any entry in the ACL 101 and are therefore dropped even before the DHCP Relay Agent can process them. That would explain why your clients actually cannot obtain IP address via DHCP in VLAN 20.

We need to add the following entry immediately before or after the existing second entry in the ACL 101:

access-list 101 permit udp any host 255.255.255.255 eq bootps

You may accomplish this by the following sequence of commands directly pasted into the global configuration:

ip access-list resequence 101 10 10
ip access-list extended 101
15 permit udp any host 255.255.255.255 eq bootps
end

The first line will cause the individual entries of the ACL 101 to be internally numbered, starting with the sequence number 10 and incrementing by 10 for each subsequent entry. The second line enters the ACL 101, treating it as a named ACL, allowing us to use the extended editing features. Finally, the third line starting with the sequence number 15 will cause the entry to be added between the existing first (seq no 10) and second (seq no 20) entry. It must be entered including the sequence number, otherwise the line will be added at the end of the ACL.

Would you mind trying out this modification? The former corrections with the NAT I have described earlier must be applied as well.

Best regards,
Peter

 

New Member

Peter,Thanks for the

Peter,

Thanks for the informative suggestion. I will try it once get in.

In terms of the oringinal config do I still need a dhcp "pool" for the guest network even if the server is looking after the DHCP requests?

Cisco Employee

Hi,In terms of the oringinal

Hi,

In terms of the oringinal config do I still need a dhcp "pool" for the guest network even if the server is looking after the DHCP requests?

Certainly not. Because the DHCP requests are forwarded thanks to the ip helper-address command to the centralized DHCP server, there is no reason to have a DHCP pool for the same network on the router.

Best regards,
Peter

New Member

Peter, This change to the

Peter,

 

This change to the config worked! I verified connectivity for the Guest-AP and everything is as its supposed to be.

 

Thanks again for your help!

Cisco Employee

Hello,It's so nice to hear

Hello,

It's so nice to hear that. Thanks!

Best regards,
Peter

4305
Views
15
Helpful
10
Replies
CreatePlease login to create content