[ 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:  Mon, 17 Nov 2008 23:43:25 +0000
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