Routing issue between VLANs ( LAN & WLAN ) on 857W

[damian_cisco]

Hello

I have an 857W which I configured to use different VLANs / IP ranges for LAN and WLAN traffic.

This works fine for traffic from both LAN and WLAN to access the internet.

The issue is that I want WLAN and LAN to be able to be able to communicate, but they don't and I don't understand why.

I'm guessing the easy way is to probably put them in the same vlan or ip range.

However I'd like to keep them separate if possible ( if for no other reason than to solve issues like this and understand better routing & vlan issues )

*Note that I understand the 857W is fairly limited in functionality ( particularly VLANs), so I may be trying to do something beyond the capabilities of the device, if thats the case then I'll give up, but I'd like to understand  "why"  this isn't working and how I can test / debug it.

Essentially the setup i have is

LAN

VLAN                    : 1

IP                    : 192.168.1.57/25

- issues DHCP with 192.168.1.0 addresses and 192.168.1.57 as default router

WLAN

VLAN                    : 11

Bridge Group          : 11

IP                    : 10.0.11.1/24

- issues DHCP with 10.0.11.0 addresses and 10.0.11.1 as default router

I thought the router would route between the 2 interfaces ( VLAN1 and BVI11 ) as long as routing was turned on, but I'm obviously missing something fundamental.

The relevant sections of my config are :

dot11 syslog

!

dot11 ssid ssid_my_wireless

   vlan 11

   authentication open

   authentication key-management wpa

   guest-mode

   wpa-psk ascii 0 <secret_obviously>

!

no ip dhcp use vrf connected

ip dhcp excluded-address 192.168.1.57

ip dhcp excluded-address 10.0.11.1

!

ip dhcp pool DHCP_POOL_LAN_ALLOCATION

   import all

   network 192.168.1.0 255.255.255.0

   default-router 192.168.1.57

   dns-server <isp_dns_servers>

!

ip dhcp pool DHCP_POOL_VLAN11_ALLOCATION

   import all

   network 10.0.11.0 255.255.255.0

   default-router 10.0.11.1

   dns-server <isp_dns_servers>

!

bridge irb

!

interface FastEthernet0

!

interface FastEthernet1

!

interface FastEthernet2

!

interface FastEthernet3

!

interface Dot11Radio0

no ip address

logging event subif-link-status

!

encryption vlan 11 mode ciphers aes-ccm

!

broadcast-key vlan 11 change 600

!

ssid ssid_my_wireless

!

speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0

station-role root

!

interface Dot11Radio0.1

description My Wireless ( WPA2 )

encapsulation dot1Q 11 native

no cdp enable

bridge-group 11

bridge-group 11 subscriber-loop-control

bridge-group 11 spanning-disabled

bridge-group 11 block-unknown-source

no bridge-group 11 source-learning

no bridge-group 11 unicast-flooding

!

!

interface Vlan1

description Vlan1 - Management Interface

ip address 192.168.1.57 255.255.255.0

ip nat inside

ip virtual-reassembly

!

interface BVI11

description Vlan11 - Bridged Interface

ip address 10.0.11.1 255.255.255.0

ip nat inside

ip virtual-reassembly

!

!

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 Dialer1

!

ip nat inside source list 10 interface Dialer1 overload

!

access-list 10 permit 192.168.1.0 0.0.0.255

access-list 10 permit 10.0.11.0 0.0.0.255

!

bridge 11 protocol ieee

bridge 11 route ip

!

Is the problem that I have a default route for everything to Dialer1 ?

The routing table is :

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     58.0.0.0/32 is subnetted, 2 subnets

C       <static_ip_address> is directly connected, Dialer1

C       <ISP_ip_address> is directly connected, Dialer1

     10.0.0.0/24 is subnetted, 1 subnets

C       10.0.11.0 is directly connected, BVI11

C    192.168.1.0/24 is directly connected, Vlan1

S*   0.0.0.0/0 is directly connected, Dialer1

This shows the 2 networks as directly connected, so I'm not sure why they don't talk.

I ran a continual ping (every 5 seconds ) from a laptop on wireless ( 10.0.11.11 ) to pc on lan ( 192.168.1.4 ) and but debug ip packet detail doesn't show any of them, i.e.

Apr 17 07:22:29.781 ACST: IP: tableid=0, s=192.168.1.57 (local), d=192.168.1.4 (Vlan1), routed via FIB

Apr 17 07:22:30.789 ACST: IP: tableid=0, s=192.168.1.57 (local), d=192.168.1.4 (Vlan1), routed via FIB

Apr 17 07:22:30.789 ACST: IP: tableid=0, s=192.168.1.57 (local), d=192.168.1.4 (Vlan1), routed via FIB

Apr 17 07:22:31.949 ACST: IP: s=192.168.1.254 (Vlan1), d=255.255.255.255, len 61, rcvd 2

Apr 17 07:22:31.949 ACST:     UDP src=53, dst=53

Apr 17 07:22:32.789 ACST: IP: tableid=0, s=192.168.1.57 (local), d=192.168.1.4 (Vlan1), routed via FIB

Apr 17 07:22:33.789 ACST: IP: tableid=0, s=192.168.1.57 (local), d=192.168.1.4 (Vlan1), routed via FIB

Any help with explaining how I've misunderstood bridging and/or how I can better debug where the packets are being dropped would be greatly appreciated.

Thanks kindly

Damian

[Richard Burts · Accepted solution]

Damian

From what you have posted I would think that routing between the VLANs should work. I am confident that the problem is not that you have the default route for everything pointed to the dialer interface. I believe that is quite proper and correct.

Probably the reason that debug is not reporting your traffic is that it is not seeing your traffic. Debug sees traffic only when the traffic is processed by the CPU. And I am guessing that your traffic is not being processed by the CPU. So I am not concerned that debug is not reporting your traffic.

Is it possible that the PC that you are trying to ping to has a firewall running and the firewall is denying the pings? If you ping that PC from a device in the same VLAN does it respond?

You might try doing a traceroute from one PC to the other. The debug ip packet should see at least part of that traffic.

Another thing that you might try is to configure an access list and apply it to the interface(s). The access list would not deny anything but it could have permits for specific traffic and a permit any any. Then show access-list would show the access list and the counters could tell if traffic was going through. It might look something like this

access-list 151 permit ip 192.168.1.0 0.0.0.255 10.0.11.0 0.0.0.255

access-list 151 permit ip any any

interface vlan 1

ip access-group 151 out

then show access-list and look to see if the counter for the first line is increasing. If so you know that traffic from vlan 11 is being forwarded to vlan 1.

You could configure a similar access list (reversing the addresses) and apply it to vlan 11 to check traffic going to that subnet.

You also might think about adding the parameter log-input to the first line of the access list. And then you would generate log messages that you could monitor to demonstrate that traffic is passing through.

Give this a try and let us know what you find.

HTH

Rick

[damian_cisco]

Hello, thanks for your response, I don't have access at the moment but I'll implement your suggestions tonight.

In terms of the ACL, should the list be applied to the interface matching the destination specified in the ACL ?

If so, I'll try the following :

access-list 101 remark Traffic from VLAN11 to VLAN01 ( WLAN -> LAN )

access-list 101 permit ip 10.0.11.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 101 permit ip any any

interface Vlan1

description Vlan1 - LAN Management Interface

ip access-group 101 out

access-list 111 remark Traffic from VLAN01 to VLAN11 ( LAN -> WLAN )

access-list 111 permit ip 192.168.1.0 0.0.0.255 10.0.11.0 0.0.0.255

access-list 111 permit ip any any

interface BVI11

desription VLAN11 - WLAN Management Interface

ip access-group 111 out

Thanks again

Damian

[Leo Laohoo]

Ummmm ... 850/W can only support one VLAN.

So I guess this is not possible because your VLAN 1 and BV1 are two different subnets. 

[damian_cisco]

Hello

Thanks everyone.

On the comment from leolaohoo I swapped out the 857W for a 877W and changed/swapped the IPs/VLANs to different ranges/numbers as it's been one of those "one day" projects I never got to and figured since I was probably going to have to strip everythign back to find the problem, now was as good a time as any.

Essentially I have the same config as posted earlier, just swapped VLAN/IP ranges

- VLAN1 as switchport ethernet interfaces with an ip range

- VLAN2 as wifi with a different ip range

I hold my hand up in admitting that I was not testing all scenarios, I was basically testing from a PC connected to LAN if I could access a NAS on the LAN, then trying to access the same NAS via the WLAN and imagining a routing / VLAN issue.

Only pinging every device from every other device ( where possible ) that the issue became clear

Essentially the scenario I discovered was

• PC could ping NAS
• L1 could  not ping NAS
• PC could ping L1
• L1 could ping PC

In the end the problem was with the NAS not having a default gateway set.

It was only drawing this picture that it really dawned on me that the NAS may be successfully receiving packets, but simply not getting them back, and that the problem was probably IP rather than VLAN/Bridging related.

Checked the NAS and sure enough, no gateway set, so presumably it was ok to respond to devices on it's own network, but would have dropped packets from a different network as it didn't know how to get them back.

So all solved now.

However, what actions / commands could I have run / monitor on the router to have readily identified that packets were being sent to the NAS but not coming back ?

Presumably, I could have

• setup an extended access list to look for VLAN2 -> VLAN1 (ip ranges) traffic and applied it to the "out" of VLAN1 to see it going out of the router
• then another access-list looking for VLAN1 -> VLAN2 ( ip ranges) traffic and applied it to the "in" of VLAN1 to look for traffic going back into the router towards the wireless lan,
• then use debug on the two access lists to spot the gap.

Is there another, more logical / easier way of fault finding on the router ( apart from checking gateway settings on devices )  ?

Thanks again

Damian

[Richard Burts]

Damian

I am glad that you got it figured out. Thanks for posting back to the forum to update us about this.

The access lists that I suggested in my post would have showed that the traffic was being forwarded from the router toward the NAS. I can not think of much of a better way to figure this out, other than perhaps doing a packet capture.

HTH

Rick