General Questions

Hi,

Don't know if it is a bug, but I notice a strange behaviour.

Here is my config :
a /24 in LAN interface going to the ip .6 in WAN, port 23. There are several ip in the /24 NATed behind the WAN ip of the monowall.
There is a rule that allow the /24 to the .6:23.

From the screenshot you can see that the trafic is sometimes blocked.
A few dropped packet and then the client is changing the source ip (automatically, it's a telnet client) and only then, there is an allowed packet.

Maybe a problem of NAT ? Maybe a problem of statefull firewall ?
I have no information and no detailed logs.
It's running version 1.233 on a soekris net48

Any idea ? It would help me a lot. This problem is putting a huge delay on each connection.
Thank you

More info:
The option "Disable port mapping" on the outbound NAT did not change anything.
Reducing the "TCP idle timeout" is not helping either :/

Anybody for an idea ? 

I really wonder if it's still reliable ...

Have you tried the "allow fragmented packets" just curious?

Yes, i've tried that too
This is a very weird problem ...
For me, it's a problem with the statefull firewall inspection, but I can't understand why.
It would be nice to have a verbose debug log or something

[status.php]

Yes, i've tried that too
This is a very weird problem ...
For me, it's a problem with the statefull firewall inspection, but I can't understand why.
It would be nice to have a verbose debug log or something

Goto http://192.168.0.1/status.php and you'll get a lot of info on m0n0wall that way. May be a bit too much, but it might help.

I tried that too. I saw nothing strange.
Do you see anything strange in this ?

Code:

tcp:
20534 packets sent
16684 data packets (20330869 bytes)
10 data packets (13183 bytes) retransmitted
0 resends initiated by MTU discovery
3274 ack-only packets (1514 delayed)
0 URG only packets
0 window probe packets
0 window update packets
566 control packets
15496 packets received
12471 acks (for 20322964 bytes)
1167 duplicate acks
0 acks for unsent data
3507 packets (752070 bytes) received in-sequence
0 completely duplicate packets (0 bytes)
0 old duplicate packets
0 packets with some dup. data (0 bytes duped)
0 out-of-order packets (0 bytes)
0 packets (0 bytes) of data after window
0 window probes
5 window update packets
9 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 connection requests
886 connection accepts
9 bad connection attempts
0 listen queue overflows
886 connections established (including accepts)
892 connections closed (including 3 drops)
104 connections updated cached RTT on close
104 connections updated cached RTT variance on close
10 connections updated cached ssthresh on close
0 embryonic connections dropped
7205 segments updated rtt (of 7216 attempts)
2 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
523 correct ACK header predictions
887 correct data packet header predictions
886 syncache entries added
1 retransmitted
0 dupsyn
0 dropped
886 completed
0 bucket overflow
0 cache overflow
0 reset
0 stale
0 aborted
0 badack
0 unreach
0 zone failures
0 cookies sent
0 cookies received
udp:
270980 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
4 with no checksum
2 dropped due to no socket
468 broadcast/multicast datagrams dropped due to no socket
0 dropped due to full socket buffers
0 not for hashed pcb
270510 delivered
274521 datagrams output
ip:
684441 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with ip length > max ip packet size
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
0 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets reassembled ok
292851 packets for this host
2 packets for unknown/unsupported protocol
229110 packets forwarded (0 packets fast forwarded)
2 packets not forwardable
0 packets received for unknown multicast group
0 redirects sent
301456 packets sent from this host
0 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
0 output packets discarded due to no route
0 output datagrams fragmented
0 fragments created
0 datagrams that can't be fragmented
0 tunneling packets that can't find gif
0 datagrams with bad address in header

Any idea, someone ?
I'm surprised to be the only one having this problem, it's quite important :/

Any idea, someone ?
I'm surprised to be the only one having this problem, it's quite important :/

I have a test m0n0wall machine, can't reproduce the problem, that's why the silence from me anyway. 

It's strange, because I have many monowalls with the same problem, all in the same config.
You have to know that the internal network in LAN is on WIFI.
Dont know if this can cause some problems, i guess not but ...

isnt it possible to have a verbose log from ipfilter ? to be sure it's not the statefull firewall that is rejecting the packet or something ?

Hello,

I had similar issues.
The solution for me was to disable ipfilter completely.
Probably there are some hidden default rules blocking allowed traffic.

Go to http://ip-address-to-m0n0wall/exec.php
Enter ipf -D to deactivate ipfilter.

If necessary, you can easily activate ipfilter again by entering ipf -E

see:
http://doc.m0n0.ch/handbook/faq-legit-traffic-dropped.html
http://doc.m0n0.ch/handbook/troubleshooting-firewall-rules.html

Hello,

I had similar issues.
The solution for me was to disable ipfilter completely.
Probably there are some hidden default rules blocking allowed traffic.

Go to http://ip-address-to-m0n0wall/exec.php
Enter ipf -D to deactivate ipfilter.

If necessary, you can easily activate ipfilter again by entering ipf -E

I'm pretty sure it's related to some ipfilter problem too.

Do you think this correction in the last beta could help ?

fixed problems when using advanced outbound NAT rules with destination matching (non-FTP connections were processed by the ipnat FTP proxy, leading to slowness, lost connections, rogue ICMP host unreachable messages etc. because ipfilter requires an additional match statement on the destination port when using proxies

Sadly this problem is still present in the current version...
I got many setup that produce the same behaviour ... I still have no clue what's going on :/

Did you look at:

http://doc.m0n0.ch/handbook/troubleshooting-firewall-rules.html

per cmb's suggestion? Which rule is actually dropping the traffic?

Steve.