Resolved

m0n0 running on a p2 with 128megs for over 2 years now.  Used as a firewall/router/vpn/traffic shaper now for about 2 years from cdrom with floppy config.  The m0n0wall connects to the inet via a cable modem to comcast.  No changes in config were made on move to b13.  I made the move for the dns patch.   

I have two windows xp machines connected to the m0n0wall.  Since the update im getting intermittent dns failures.  The m0n0wall is configured via dhcp to be the dns server for the two workstations.   While browsing with firefox I will occasionally receive a site not found msg.  This has happened several times over the past few days on several sites.   I realize this may be an issue with comcast dns server as they probably updated their servers too.   I just want to relate this possible bug and ask for guidance in testing for the problem.  It's intermittent so I dont know the best way to test.  I realize I could change back to older version and test, I also could directly connect a workstation to the internet.  Honestly, I just wanted to bring this to your attention and see if anyone else has noticed the issue.   This dns patch was huge and their are bound to be issues.

Just wanted to add some information.  I just did a series of nslookup requests from the xp machines.  About 1 of 10 lookups are timing out.  Less the 1ms latency between xp box and m0n0.  avg 18ms between m0n0 and dns server.   As you can see the server did end up responding that time.  Sometimes it never responds at all.  Is there a way to run an nslookup from the m0n0wall?

> www.sprint.com
Server:  m0n0wall.local
Address:  192.168.2.1

Non-authoritative answer:
Name:    www.sprint.com
Addresses:  206.159.101.241, 65.173.211.241

> www.ford.com
Server:  m0n0wall.local
Address:  192.168.2.1

DNS request timed out.
    timeout was 2 seconds.
Non-authoritative answer:
Name:    a1200.g.akamai.net
Addresses:  64.208.21.49, 64.208.21.43
Aliases:  www.ford.com, www.ford.com.edgesuite.ne

>

under "General Setup" set your DNS servers to:

208.67.222.222
208.67.220.220

and uncheck the box: "Allow DNS server list to be overridden by DHCP/PPP on WAN"

and give that a try.

CS...

Okay I changed the dns servers and unchecked the override.   Still timing out.   This an nslookup session from the xp machine.

> www.yack.com
Server:  m0n0wall.local
Address:  192.168.2.1

Non-authoritative answer:
Name:    www.yack.com
Address:  208.67.217.132

> www.cool.com
Server:  m0n0wall.local
Address:  192.168.2.1

DNS request timed out.
    timeout was 2 seconds.
*** Request to m0n0wall.local timed-out
> www.cool.com
Server:  m0n0wall.local
Address:  192.168.2.1

DNS request timed out.
    timeout was 2 seconds.
Non-authoritative answer:
Name:    cool.com
Address:  72.32.79.195
Aliases:  www.cool.com

> www.cool.com
Server:  m0n0wall.local
Address:  192.168.2.1

Non-authoritative answer:
Name:    cool.com
Address:  72.32.79.195
Aliases:  www.cool.com

>

Hmm, do you have inbound NAT on large ranges of ports set up by chance? The problem with randomly picking a port (as the patched Dnsmasq in 1.3b13 does) is that it could accidentally pick a port where it will never see the reply from the upstream DNS server because it gets NATed.

Giving Dnsmasq a smaller port range could mitigate this, but we'd then lose a lot of the additional unpredictability that the whole source port randomization dance is intended to introduce. OTOH, maybe there should be an option to disable the randomization - I think the author of Dnsmasq still believes that Dnsmasq itself is not vulnerable (because it doesn't do recursion on its own), but we'll only know for sure once Kaminsky's released the full details.

Yes, you are a smart man Mr. Kasper.   The moment I read your first sentence it all made sense.  I left out one thing in my configuration.  I have a Vonage adapter and per their instructions I forward all incoming UDP packets from 10000-20000 to the Vonage adapter.   Now I see what is happening.   I too am anxiously awaiting details of the dns issue.   I've read his blog and he very clearly states that ALL dns servers are vulnerable even those behind a firewall.  He managed to scare the BIG players into doing this patch and as far as I can tell the exploit hasn't leaked yet... surprising really.  This was my main reason for upgrading to the latest beta.

I guess this isn't a bug, more of an implementation issue previously unseen, so please do what you'd like with this thread.  However you may want to point out elsewhere that if you are using inbound nat on large ranges you a VERY likely to miss dns responses.  I'm quite certain im not the only one using a m0n0wall to traffic shape my lan for the VOIP traffic.  In fact when I asked about call quality problems when I first got Vonage they recommended a m0n0wall.  I must say it is a beautiful implementation.  Before I learned about m0n0wall I intended on setting up a linux machine to do the job as I have more experience with that.  Once I saw your software in action I never looked back.  It does everything I need and nothing I don't.   I do have a feature request also,  with the increasing use of EVDO wireless it would be awful nice if we could get that working in freebsd.   Ive looked into it and aparently the driver is not yet ready.   For a client I had to purchase a Sonicwall TZ 190 because it has support for WWAN over EVDO via a PCMCIA slot.   This client is in a remote location without access to high speed internet but with access to an EVDO network.  The EVDO network is also an excellent fallback network.  Usb tokens are now available that can hop on evdo as well.  You could seriously increase the usefulness of m0n0wall by adding this function as soon as they sort out the driver issues.  They connect using a standard ppp dialup so im sure it would only take a few tweeks to the config on your part.   The fallback option may require more code but I doubt it would be to difficult. 

I will be contacting the folks at Vonage about the issue to see if they can narrow that source range.  I would imagine they use it for some sort of pseudo security randomization just like the dns patch....   

Again thank you Mr. Kasper for your fine software and quick answer.

Version 1.234 also has this issue. Had to revert to 1.233 until it's fixed or there is an option somewhere to specify a port range for Dnsmasq (as there is with outbound NAT). Which makes me wonder, is ipnat port mapping aware or will we see similar issues due to source port randomization for it also unless we specify an unmapped port range?

Update: 1.235 and 1.3b14 contain a fix that should take care of this issue, even with large ranges of inbound NAT mapped ports.

No issues so far, looks like that did the trick. Thanks Manuel!