Chapter 15. FAQ

Table of Contents

15.1. How can I prioritize ACK packets with SmallWall?
15.2. Why isn't it possible to access NATed services by the public IP address from LAN?
15.3. I enabled my PPTP server, but am unable to pass traffic into my LAN
15.4. I just added a new interface to my SmallWall box, and now it doesn't show up in the webGUI!
15.5. Does SmallWall support MAC address filtering?
15.5.1. Using Captive Portal and MAC pass-through
15.5.2. Using DHCP reservations and firewall rules
15.5.3. Using Static ARP
15.6. Does SmallWall support SMP systems?
15.7. Why can't hosts on a NATed interface talk to hosts on a bridged interface?
15.8. What were the goals behind the m0n0wall project?
15.9. So what are the goals behind the SmallWall project?
15.9.1. Do one thing, and do it well.
15.9.2. Small, lean and efficient code.
15.9.3. Security, security, security...
15.10. How do I setup multiple IP addresses on the WAN interface?
15.10.1. Proxy ARP
15.11. Can I filter/restrict/block certain websites with SmallWall?
15.12. Why are some passwords stored in plaintext in config.xml?
15.13. Are there any performance benchmarks available?
15.14. What about hidden config.xml options?
15.15. Why can't I query SNMP over VPN?
15.16. Can I use SmallWall's WAN PPTP feature to connect to a remote PPTP VPN?
15.17. Can I use multiple WAN connections for load balancing or failover on SmallWall?
15.18. Can I access the webGUI from the WAN?
15.18.1. When using static IP on WAN
15.18.2. When using dynamic IP on WAN
15.19. Can I access a shell prompt?
15.20. Can I put my configuration file into the SmallWall CD?
15.21. How can I monitor/graph/report on bandwidth usage per LAN host?
15.22. Will there ever be translated versions of SmallWall? Can I translate SmallWall into my language?
15.23. Does SmallWall support transparent proxying?
15.24. Should I use SmallWall as an access point?
15.25. Why am I seeing traffic that I permitted getting dropped?
15.26. How can I route multiple subnets over a site to site IPsec VPN?
15.26.1. Summarizing the subnets using a larger mask
15.26.2. Setting up multiple IPsec connections
15.27. How can I block/permit a range of IP addresses in a firewall rule?
15.28. Why does my MSN Messenger transfer files very slowly when using traffic shaper?
15.29. Can I forward broadcasts over VPN for gaming or other purposes?
15.30. How can I use public IP's on the LAN side? Or how can I disable NAT?
15.31. Are PCMCIA cards supported?
15.32. Are there any tweaks for systems that will need to support large loads?
15.33. Can I add MRTG or some other historical graphing package to SmallWall?
15.34. Can Captive Portal be used on a bridged interface?
15.35. Can I run Captive Portal on more than one interface?
15.36. Why do my SSH sessions time out after two hours?
15.37. Why am I seeing "IP Firewall Unloaded" log/console messages?
15.38. Why can't my IPsec VPN clients connect from behind NAT?
15.39. Why doesn't SmallWall have a log out button?
15.40. Can I sell SmallWall (or use it in a commercial product)?
15.41. When will SmallWall be available on a newer FreeBSD version?
15.42. Is there any extra Captive Portal RADIUS functionality available?
15.43. How can I increase the size of the state table?

Everything you ever wanted to know about SmallWall but were afraid to ask.

15.1. How can I prioritize ACK packets with SmallWall?

On asymmetric Internet links like DSL and often Cable, a big upload that consumes all of the available upstream bandwidth can render the link almost unusable by producing a huge backlog in the DSL/Cable modem's buffer, thus increasing the delay to several seconds. Because ACK packets (TCP acknowledgments) for received data are delayed or even lost as well, download speed drops, too.

This problem can be solved by prioritizing these ACK packets, so they will be sent out before any other upload packets. Here's how to do it with SmallWall:

Start by adding a new pipe to the traffic shaper. This is necessary because we need to move the upstream queue into SmallWall (where the order in which packets are sent out can be changed while packets are in the queue) rather than the DSL/Cable modem. Once the packets are in the DSL/Cable modem's output queue, there's no way of having ACK packets sent out immediately anymore. Therefore, it is very important to set that pipe's bandwidth to a value that is slightly below the effective upstream bandwidth of your Internet link. Don't forget that e.g. 128 kbps ADSL line speed is only about 100 kbps effective. If you set this value too high, your modem buffer will still become full and prioritization will accomplish nothing.

When you have added that pipe, add two queues linked to that pipe with different weights, e.g. one queue with weight = 10 and one with weight = 1. The first queue becomes your high priority queue.

Now it's time to add rules that classify upstream traffic into one of these two queues. There are loads of possibilities, e.g. prioritizing by TCP/UDP port, but for now we'll focus on IP packet length and TCP flags. Add a new traffic shaper rule, link it to the first (high-priority) queue, interface = WAN, protocol = TCP, source = any, destination = any, direction = out, IP packet length 0-80, TCP flags: ACK = set, everything else = don't care. It is not sufficient to classify packets into the high-priority queue based on the ACK flag only, because (big) upstream TCP data packets can have the ACK flag set as well. 0-80 is just an example to get you started. Save the rule, and add another one below it, linked to the second (low priority) queue, interface = WAN, protocol = any, source = any, destination = any, direction = out. Enable the traffic shaper if necessary, apply the changes - that's it. Here are a few points to remember:

  • Make sure no upstream Internet traffic can bypass the pipe

  • Despite ACK prioritization, the delay will still go up, as it is not possible to stop sending a big packet mid-way. For example, a full-size (1500 bytes) packet at 100 kbps will take 120 ms

  • If you want to be able to surf the web while performing a large upload, you'll also have to prioritize HTTP upstream traffic (i.e. destination port = 80) - otherwise, TCP SYN packets (for connection establishment) to web servers will not get prioritized, and there will be a big initial delay until a connection is established. Prioritizing DNS packets is a good idea as well.

  • If you want to find out what prioritization does for you, add a rule to classify outgoing ICMP packets into the high-priority queue and try pinging some Internet host while you're uploading - once with the traffic shaper on, and once off. There should be a huge difference in response times.