1. Transparent Firewall for Wireless Network
Kasom Koth-arsa1, Surasak Sanguanpong2, Anan Phonphoem2 {Kasom.K, Surasak.S,
1Engineering Computer Center, Faculty of Engineering
2Department of Computer Engineering, Faculty of Engineering
Kasetsart University
APAN, Hawaii, Network Security, 23rd Januray 2008
This work is partially supported by Commission of Higher Education (CHE), UniNET, Thailand

2. Agenda Backgrounds Obstacles & Opportunities Design Implementation
Conclusion

3. Kasetsart University Wireless Network
Kasetsart University Wireless Network – KUWiN
Centralize control, managed by Office of Computer Services
452 APs in Bangkhen campus (As of 2008/01/18)
200 more APs will be deploy within the next three month
110 Buildings
34,780 registered wireless devices
More than 2,000 maximum concurrent clients

4. Currently 452 APs available (2008/01/18)
KUWiN
Currently 452 APs available (2008/01/18)
Campus
Ministry of Agriculture
1.5 km

5. Agenda Backgrounds Obstacles & Opportunities Design Implementation
Results
Conclusion

6. Obstacles & Opportunities
Large number of concurrent clients
More than 2,000 maximum concurrent clients
Require large number of IP addresses
Rouge DHCP server and broadcast storm in Wireless Network
User use static IP address
Conflict with the user who uses DHCP
Wireless roaming within the campus

7. Agenda Backgrounds Obstacles & Opportunities Design Implementation
Results
Conclusion

8. Design: The Two Extreme
Single subnet for the whole wireless network
Efficient IP address utilization
Seamless roaming
Suffer from broadcast problems
Multiple subnet, one for each access point
Separate broadcast domain, separate the problems
Not smooth roaming
IP address utilization is not efficient

9. Design: Previous KUWiN
Single VLAN across the whole campus, dedicated for wireless network
Single subnet, single broadcast domain
Router
Ethernet Switch
Ethernet Switch
Ethernet Switch
Ethernet Switch AP AP AP AP AP AP AP AP AP
Single VLAN/Single subnet

10. Design: The New KUWiN Multiple VLANs Shadow VLANs
Network Management VLAN
Registration VLAN (For the users to register their devices’ MAC address)
Unencrypted VLAN: KUWIN (For legacy clients)
WPA VLAN: KUWIN-WPA
Shadow VLANs
Split the unencrypted and WPA VLAN into multiple VLANs
Join those VLAN together with transparent bridge/firewalls

11. Design: Shadow VLANs
The network management VLAN and the registration VLAN are not shadowed
Both the unencrypted VLAN and the WPA VLAN are divided into N Shadow VLAN each
Some broadcast packets will be filtered using transparent firewalls, thus create a single subnet with (somewhat) multiple broadcast domains

12. Design: Shadow VLAN/Logical View
Router
Multiple VLAN/Single subnet
Ethernet Switch
Primary VLAN
Transparent
Firewall
Transparent
Firewall
Transparent
Firewall
Ethernet Switch
Ethernet Switch
Ethernet Switch AP AP AP AP AP AP AP AP AP
Shadow VLAN #1
Shadow VLAN #2
Shadow VLAN #3

13. Design: VLAN Partitioning
Selecting the number of Shadow VLANs
Cost of firewall servers
Ease of management
Effectiveness of separating the broadcast domain

14. Design: Filtering DHCP ARP NetBIOS broadcast/other broadcasts
Allow request from client side to the router
Allow reply from the router to the client
ARP
Assume that all wireless users are clients, the clients will always issue the ARP request
Drop requests from the router
NetBIOS broadcast/other broadcasts
Drop all
Design a daemon to permitting DHCP users/blocking static IP users (Adjust the ipset)

15. Design: Force User to Use DHCP
Router/DHCP Server Side
DHCP Offer/ACK Packets
Bridge/
Transparent Firewall
Daemon
ipset Member Database
update
Client Side

16. Agenda Backgrounds Obstacles & Opportunities Design Implementation
Results
Conclusion

17. Implementation: Overview
Use two large subnet, 16 class C each
The first subnet is for unencrypted VLAN
The second subnet is for the WPA VLAN
Split both unencrypted and WPA VLAN into 5 VLAN each
Use transparent firewall/bridge to tie those VLANs together

18. Implementation: Transparent bridge/firewall
Use Linux server as a bridge
Iptables + ipset & ebtables
Focus on filtering of broadcast packets
DHCP
ARP
NetBIOS broadcast

19. Implementation: Hardware
Sun Fire X2100
Opteron™ 1210 Dual core(1.8 GHz)
512MB of RAM
300 GB SATA hard disk
Built-in Gigabit Ethernet Controller

20. Implementation: Software
Linux ipset patch on CentOS 5 (64 bit)
bridge-utils
ebtables
Iptables ipset patch
Create a daemon for permitting DHCP users/blocking static IP users (Adjust the ipset)

21. Implementation: Filtering/ebtables
Bridge chain: FORWARD, entries: 18, policy: ACCEPT
-d 1:0:5e:0:0:2 -j DROP
-d 1:0:5e:0:0:5 -j DROP
-d 1:0:5e:0:0:d -j DROP
-d 1:0:5e:7f:ff:fa -j DROP
-d 1:0:c:cc:cc:cd -j DROP
-d 1:0:c:cc:cc:cc -j DROP
-d BGA -j DROP
-d 33:33:0:0:0:5 -j DROP
-p ARP -d Broadcast -i eth2 -j DROP
-p ARP -j ACCEPT
-p IPX -d Broadcast -j DROP
-p NetBEUI -d Broadcast -j DROP
-p IPv4 -d Broadcast --ip-proto udp --ip-dport 137:138 -j DROP
-p IPv4 -d Broadcast -i eth ip-proto udp --ip-dport 68 -j DROP
-p IPv4 -d Broadcast -o eth ip-proto udp --ip-dport 67 -j DROP
-p IPv4 -j ACCEPT
-p IPv6 -j ACCEPT
-j DROP

22. Implementation: Filtering/iptables
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT /0 PHYSDEV match --physdev-in eth3.112
ACCEPT / /0 PHYSDEV match --physdev-in eth3.112 \
set fixip src,src
set usedhcp src,src
LOG / /0 PHYSDEV match --physdev-in eth3.112 \
LOG flags 0 level 4
DROP / /0 PHYSDEV match --physdev-in eth3.112

23. Implementation: Filtering/ipset
Name: fixip
Type: ipmap
References: 1
Default binding:
Header: from: to:
Members:
X.X …
Bindings:
Name: usedhcp
Type: macipmap
X.X:XX:XX:XX:XX:XX:XX
Manually insert to allow some IP to be set statically.
Automatically insert/remove
By the daemon to allow
DHCP users

24. Agenda Backgrounds Obstacles & Opportunities Design Implementation
Results
Conclusion

25. Results From our experiments
ARP broadcast from the router is greatly reduced
Rouge DHCP server still disturbed the local VLAN in which it is connected to but no longer effect the other Shadow VLAN, thus the scope is smaller
The latency introduced by adding transparent firewall is very small

26. Agenda Backgrounds Obstacles & Opportunities Design Implementation
Results
Conclusion

27. Conclusions
A wireless network deployment that combine the efficient IP address allocation of single subnet design with the (partial) broadcast domain separation of multiple subnet design
Rouge DHCP server will not effect the whole subnet
The number of broadcast is reduced
Roaming within the campus is seamless
Prevent the users from using static IP address in the wireless network

28. Future Works
Rouge Access Point Detection and Blocking

29. Thank you!
Questions?