[ previous ] [ next ] [ threads ]
 
 From:  "Neil A. Hillard" <m0n0 at dana dot org dot uk>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Performance difference between 1.235 and 1.3b15
 Date:  Wed, 3 Dec 2008 00:54:13 +0000
Hi,

Yet another post on this bug!

In message <iFuwxBC7rrMJFwrt at dana dot internal dot dana dot org dot uk>, Neil A. Hillard 
<m0n0 at dana dot org dot uk> writes
>Hi,
>
>In message <0vDVruFdGgIJFwaN at dana dot internal dot dana dot org dot uk>, Neil A. 
>Hillard <m0n0 at dana dot org dot uk> writes
>>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,
>
>
>Does anyone have any ideas on this?  I've done lots of searching for 
>FreeBSD bugs relating to this particular problem and can't find 
>anything!
>
>This bug is really killing Internet performance and I can't go back to 
>1.235 because I need to filter incoming ipsec connections!
>
>Any advice would be seriously appreciated!

I've done a fairly un-scientific test on all of the 1.3 beta releases!

I can report that this NAT bug appears to affect 1.3b1 thru 1.3b15 so it 
looks to be a FreeBSD 6.2/6.3 bug!

My testing consisted of accessing one specific web site with and without 
the advanced NAT enabled and measuring the total time to load the page. 
With advanced NAT enabled, page load times ranged from 13 to 47 seconds 
whereas with advanced NAT disabled page load times were 2 to 7 seconds! 
Quite a difference!

The testing with the NAT rule was performed with a single NAT rule that 
had a target of 'NOT 192.168.0.0/24' which should always hit as I've not 
got a 192.168.0.0/24 network connected to the m0n0wall!

I'd love to go back to 1.235 to improve performance but I need to be 
able to filter the ipsec connection!  Is there any way of doing this 
with 1.235?

Many thanks in advance,


Neil.

-- 
Neil A. Hillard                E-Mail:   m0n0 at dana dot org dot uk