Firewall/NAT

So I'm trying hard to get another LAN connected to m0n0wall, but I already fail at trying to set up a rule to allow to ping the m0n0wall from the new network.

The OPT1 network is 192.168.3.0/24, m0n0wall if is 192.168.3.1
Having a client with IP 192.168.3.12

For testing purposes I added a rule to OPT1 to allow any protocol from any to any host.
But when I try to ping the m0n0wall, it tries to send the echoreply packet on the WAN interface where it gets blocked due to the "block private addresses" rule.
Why is m0n0wall even chosing this interface to try to send the echoreply? Its like it doesn't know that OPT1 has this subnet.
I tried to add a static route for this purpose, but I didn't really know what would be the correct one.

This is the log entry for the firewall:
20:50:14.158873   WAN   192.168.3.1   192.168.3.12, type echoreply/0   ICMP

OK I could solve that one by rebooting... Now I can ping the m0n0wall and even access all allowed hosts.
Only thing that does not work is DHCP.

I don't even see any blocked packets or dhcp requests in the log. Any ideas?
And yes... I enabled the DHCP server for that interface

If your DHCP server is set for this interface and the firewall full opened, I do not understand...

Can you monitor the interface of your client (ie with WireShark) to see DHCP request (and eventually response ?)

Yes, I already did that, and I can see the requests, but no replies...
The only point is that the clients are behind a wireless bridge that is connected to the OPT1 port.
Although I doubt that it is filtering or dropping DHCP packets I'll check what happens if I use a fully wired setup at the OPT1 interface as soon as possible.

OK, tested it with a wired connection now. Same thing, only pinging m0n0wall works, everything else is just dropped it seems. Still no blocking/rejecting events in the Log.
There should be DHCP, DNS, PPTP and HTTPS working on that interface as far as I understand.


I attached screens from my config. Maybe I'm just not seeing it.

Rules seems to be ok.

Can you remove the 2 last rules for tests to be sure ?

"Deny unknown clients" is unchecked in your WLAN DHCP server ?

Can you reach an other interface with a client (with static IP set) from WLAN ? (wired)

Are you using vlans ?

Continue you tests with wired client, it remove the possiblity of filtering with the bridge...

Removed the 2 extra rules.

I checked the DHCP settings, unknown hosts are not denied.

Pinging other interfaces of the m0n0wall works, I can even ping hosts on the internet by their IP address. Everything else gets filtered.

Also there are no VLANs set/used anywhere.

Already disabled unnecessary stuff like the traffic shaper and IPv6 (what I normally need, that's why I'm using the latest beta)

Also, when I change the Protcol of the "allow everything" rule to TCP or UDP, pinging doesn't work anymore (as it is to be expected), but connecting to m0n0wall or anywhere else still fails.


Another update:
I just noticed the interface has a lot of incoming packet errors... So my (maybe a bit far fetched) guess is that the TCP/UDP checksum offloading is not working, and thus all packets are dropped because they are considered erroneous. I tried to disable it by going to exec.php and running "ifconfig fxp1 -rxcsum -txcsum" but the options do not get removed when checking with "ifconfig fxp1"...

Hsssnggg *calms down*


I finally found the cause. It was the link0 flag that gets set on the interface by default.

After hours of fiddling, swearing, reconfiguring and googling I stumbled upon this thread:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2004-02/1186.html


The 40 byte thing made perfect sense, also that he said he could only ping the box, as ping packets are <40 bytes.
So doing "ifconfig fxp1 -link0" did the magic and now everything works as expected.

I'll check if some php file sets this flag and remove it.


Update: So it seems it was sufficient to just remove the few occurrences in interfaces.inc where the link0 flag got added to the parameters to ifconfig.
As far as I understand this feature normally helps saving some CPU time (if it works), so it should not generally be removed.
Maybe its faulty drivers in FreeBSD, maybe faulty hardware, maybe both. I'm not the expert here. It might be nice to have an extra option in the web interface to disable this feature, with a hint to the symptoms. Might save someone else some sleepless nights..
In my case the card was an Intel PRO/100 S Dual Port Server Adapter.