|
||||||||
Hi, In message <a$nevrCOZBIJFwvT at dana dot internal dot dana dot org dot uk>, Neil A. Hillard <m0n0 at dana dot org dot uk> writes >Hi, > >In message ><d64aa1760811150914v5df96cc8q1d87814ef70f4626 at mail dot gmail dot com>, Chris >Buechler <cbuechler at gmail dot com> writes >>On Sat, Nov 15, 2008 at 4:07 AM, Neil A. Hillard <m0n0 at dana dot org dot uk> wrote: >>> >>> Hopefully sometime this weekend I'll get 1.3b15 on my test box and start >>> building the configuration from scratch and see if a basic configuration >>> suffers the same performance problem. >>> >>> Is there a list of NICs that support hardware VLAN tagging for 1.3? >> >>Should be the same as those in 1.2, plus some. >> >> >>> Is there a >>> recommendation for a decent card? There seems to be plenty of Intel >>> Pro/100 and Pro/100 S on eBay going at a sensible price! Not sure if >>> the onboard 82558 supports VLAN tagging natively. >>> >> >>Pro/100s are the best low cost way to go. Pro/1000s are faster (well, >>use less CPU) even at 100 Mb, about a 15% increase in throughput where >>the CPU wasn't fast enough (Pentium 200 MHz) to push 100 Mb wire speed >>in testing I've done. >> >>But that may not fix your problem, and while I'm pretty sure what >>you're seeing is large frames getting lost, that hasn't been >>confirmed. >> >>First, drop the MTU on one of your hosts to 1400. If the problem goes >>away for that host, that confirms my suspicion is correct. Then post >>the ifconfig output for your VLAN parent interface from m0n0wall. > >I've tested dropping my MTU size to 1400 but that seems to make things a >touch more responsive but not what it should be! > >I've managed to do some other testing and have configured my test >firewall with 1.3b15, with the same interface configuration (except for >different VLAN IDs) and luckily I have a spare external IP address so >I've been able to do this without having to affect my live >configuration. > >I believe I have however confirmed that this is an advanced outbound NAT >problem! > >If I enable advanced outbound NAT and add one rule: > >Interface Source Destination Target >WAN 192.168.1.0/24 * * > >everything is fine. If however I add a negation to the destination: > >Interface Source Destination Target >WAN 192.168.1.0/24 ! x.y.z.0/29 * > >the problem shows itself. > >I need to basically have the second form so that I can access my >services on my Internet facing DMZ (bridged to WAN), otherwise: > >http://doc.m0n0.ch/handbook/faq-bridge.html > >prevents me from accessing the services (I really must get the FAQ >updated as the key to accessing devices on a bridged interface is to >prevent them from being NATed - I've had it working for years so far)! > >I've done a quick bit of searching for ipnat bugs that could cause this >issue but I haven't come across anything! Apologies for following up my own post but I've done a little more testing. I've gone back to 'factory defaults' and configured the following: o Two physical interfaces (LAN and WAN) o LAN address (192.168.235.1/24) o WAN address (x.y.z.3/29) o LAN DHCP Server address range (192.168.235.100-199) o DNS Servers Everything performs nice and quickly! Enabling advanced outbound NAT and adding in the following rule Interface Source Destination Target WAN 192.168.235.0/24 * * Results in a perfectly functioning m0n0wall, with the following displayed for ipnat -lv: List of active MAP/Redirect filters: map xl0 192.168.235.0/24 -> 0.0.0.0/32 proxy port ftp ftp/tcp map xl0 192.168.235.0/24 -> 0.0.0.0/32 portmap tcp/udp 1024:64535 map xl0 192.168.235.0/24 -> 0.0.0.0/32 map xl0 from x.y.z.3/32 to any port = 53 -> 0.0.0.0/32 tcp/udp Changing the destination in the NAT rule as follows: Interface Source Destination Target WAN 192.168.235.0/24 !192.168.0.0/24 * Results in the huge delays that I'm seeing. ipnat -lv gives: List of active MAP/Redirect filters: map xl0 from 192.168.235.0/24 ! to 192.168.0.0/24 -> 0.0.0.0/32 proxy port ftp ftp/tcp map xl0 from 192.168.235.0/24 ! to 192.168.0.0/24 -> 0.0.0.0/32 portmap tcp/udp 1024:64535 map xl0 from 192.168.235.0/24 ! to 192.168.0.0/24 -> 0.0.0.0/32 map xl0 from x.y.z.3/32 to any port = 53 -> 0.0.0.0/32 tcp/udp I'm testing this with by accessing my router (x.y.z.1). When there's no NAT problem the prompt for password authentication appears immediately whereas with the problem it takes about 3 seconds! Any advice would be appreciated! If you need any further details then please let me know. Many thanks in advance, Neil. -- Neil A. Hillard E-Mail: m0n0 at dana dot org dot uk |