Users connecting to ssid1 with wpa2ent, therefore we can trust them to be authenticated users. They should simply grab an ip address from the 192.168.40.0/24 network and be online.
Users connecting to ssid2 are connecting to a completely open network. I want those users to be routed through the openwrt metarouter and sent to our captive portal. The openwrt metarouter should also give out dhcp on the 192.168.75.0/24 network. Once they log in via the browser they are able to access the network by being natted through vif2 onto the 192.168.40.0/24 network.
All of this is happening via one ethernet cable connecting ether1 on the mikrotik box to the ethernet port of our AP. The ap puts all traffic coming from the ssid1 network onto the wire untagged, and traffic from the ssid2 network is tagged with vlan ID 10.
From here we are at ether1 in routeros.
I have 2 bridges setup, def_bridge and meta_bridge.
The def_bridge includes the ether1 port and the vif2 port from the metarouter. Traffic flows fine from interface to virtual interface on this bridge. The metarouter can ping out via vif2. Users connected to the ssid1 network are also able to get online without issue.
The meta_bridge includes a vlan interface which is a child of the ether1 port, this of course being vlan ID 10, and vif1 from the metarouter. I can see vlan ID 10 tagged traffic coming into the metarouter from users on ssid2, however no traffic will go back out through ether1 with vlan ID 10. I don't really know where the traffic goes at this point.
my configuration is as follows in routeros:
I'm aware I left out dhcp-server and other items that don't have anything to do with the problem. I did not want to dilute the explanation of topology.
my openwrt metarouter configuration:
Code: Select all
/interface vlan add interface=ether1 name=vlan10 vlan-id=10 /interface bridge add name=def_bridge /interface bridge port add bridge=def_bridge interface=ether1 /interface bridge add name=meta_bridge /interface bridge port add bridge=meta_bridge interface=vlan10 /ip address add address=192.168.40.1/24 broadcast=192.168.40.255 comment="" disabled=no \ interface=def_bridge network=192.168.40.0 /metarouter add comment="" disabled=no disk-size=unlimited memory-size=32MiB name=mr2 /metarouter interface add comment="" disabled=no dynamic-bridge=meta_bridge dynamic-mac-address=\ 02:43:D0:8E:3A:BB type=dynamic virtual-machine=mr2 vm-mac-address=\ 02:66:8F:FC:F9:BC add comment="" disabled=no dynamic-bridge=def_bridge dynamic-mac-address=\ 02:11:9B:FF:98:AA type=dynamic virtual-machine=mr2 vm-mac-address=\ 02:BE:3D:6B:E9:D0
Once again, I realize I left out dhcp and other things that would dilute the problem.
As I said, def_bridge is working fine. From openwrt I can ping 192.168.40.1 without issue.
Code: Select all
root@OpenWrt:/# cat /etc/config/network # Copyright (C) 2006 OpenWrt.org config interface loopback option ifname lo option proto static option ipaddr 127.0.0.1 option netmask 255.0.0.0 config interface lan option ifname eth0 option type bridge option proto static option ipaddr 192.168.75.1 option netmask 255.255.255.0 config interface wan option ifname eth1 option type bridge option proto static option ipaddr 192.168.40.2/24 option netmask 255.255.255.0 option gateway 192.168.40.1 option dns 192.168.40.1
The problem arises with the ether1:vlan10/vif1 side. I cannot get vlan tagged traffic going correctly. Everyone's first question is going to be, are you sure that the access point is correctly tagging traffic. I am very sure that the ap is correctly tagging traffic, confirmed by ethereal and it working with other vlan equipment we use around here.
As a side note, the only other way of configuring this that I can think of would be to drop routeros' knowledge of the vlan completely. I.E. simply bridge vif1 and ether1 and get rid of ether1:vlan10, vif2, and meta_bridge completely. Then in the openwrt configuration I can create 2 interfaces, eth0 and eth0.10 which would should work, but I don't see any reason the current configuration shouldn't work either.
Any help would be greatly appreciated, thank you!