Colin Wetherbee wrote: > Hello. > > I've been using Vuurmuur for several months, and I enjoy the ease of use. > However, I've recently started using Vuurmuur on a machine that is connected > to four subnets, and I'm getting strange and (seemingly) random dropped > connections. > > The problem is easiest to find when using SSH because it's rather obvious when > the terminal simply stops responding. Typically, when it stops responding, > the connection is never re-established, and eventually, the SSH keep-alive > decides to tear the connection down. > > Here is an excerpt from my log when trying to establish an SSH connection from > 172.20.40.22 (on 172.20.40.16/28) to 172.20.40.2 (on 172.20.40.0/28). > > Nov 13 01:22:06 lamp kernel: [995035.585604] vrmr: DROP fw INVALID IN=eth1 > OUT=eth1 SRC=172.20.40.22 DST=172.20.40.2 LEN=500 TOS=0x10 PREC=0x00 TTL=63 > ID=38200 DF PROTO=TCP SPT=55240 DPT=22 WINDOW=190 RES=0x00 ACK PSH URGP=0 > Nov 13 01:22:06 lamp kernel: [995035.586490] vrmr: DROP fw INVALID IN=eth1 > OUT=eth1 SRC=172.20.40.22 DST=172.20.40.2 LEN=64 TOS=0x10 PREC=0x00 TTL=63 > ID=38201 DF PROTO=TCP SPT=55240 DPT=22 WINDOW=190 RES=0x00 ACK URGP=0 > Nov 13 01:23:00 lamp kernel: [995088.831944] vrmr: DROP fw INVALID IN=eth1 > OUT=eth1 SRC=172.20.40.22 DST=172.20.40.2 LEN=500 TOS=0x10 PREC=0x00 TTL=63 > ID=38202 DF PROTO=TCP SPT=55240 DPT=22 WINDOW=190 RES=0x00 ACK PSH URGP=0 > Nov 13 01:23:00 lamp kernel: [995088.832681] vrmr: DROP fw INVALID IN=eth1 > OUT=eth1 SRC=172.20.40.22 DST=172.20.40.2 LEN=64 TOS=0x10 PREC=0x00 TTL=63 > ID=38203 DF PROTO=TCP SPT=55240 DPT=22 WINDOW=190 RES=0x00 ACK URGP=0 > Nov 13 01:23:47 lamp kernel: [995136.582270] vrmr: DROP no SYN IN=eth1 > OUT=eth1 SRC=172.20.40.2 DST=172.20.40.22 LEN=84 TOS=0x10 PREC=0x00 TTL=63 > ID=53279 DF PROTO=TCP SPT=22 DPT=43738 WINDOW=239 RES=0x00 ACK PSH URGP=0 > > As you can see, the errors are typically a combination of "DROP fw INVALID" > and "DROP no SYN". > > I'm using the following interfaces for the relevant subnets on the machine > running Vuurmuur. The eth1:N interfaces are the usual Linux virtual > interfaces. > > eth1 Link encap:Ethernet HWaddr 00:03:93:8d:c2:fe > inet addr:172.20.39.1 Bcast:172.20.39.255 Mask:255.255.255.0 > -- > eth1:1 Link encap:Ethernet HWaddr 00:03:93:8d:c2:fe > inet addr:172.20.40.1 Bcast:172.20.40.15 Mask:255.255.255.240 > -- > eth1:2 Link encap:Ethernet HWaddr 00:03:93:8d:c2:fe > inet addr:172.20.40.17 Bcast:172.20.40.31 Mask:255.255.255.240 > -- > eth1:3 Link encap:Ethernet HWaddr 00:03:93:8d:c2:fe > inet addr:172.20.40.33 Bcast:172.20.40.63 Mask:255.255.255.224 > > I also have an eth0 on this machine, which is a WAN connection with a dynamic > IP address (with SNAT rules to the 172.20.x.x subnets in Vuurmuur). I do not > see the errors described above on connections between the WAN and the > 172.20.x.x LAN. > > My Vuurmuur rules connecting the 172.20.x.x subnets to each other are all > "accept any". > > To the Vuurmuur configuration, itself, I believe the only modifications I have > made to the default have been to remove the limits on new TCP and UDP > connections, as these were causing rapid DNS look-ups to fail frequently. > > I've tried some of the more obvious solutions, but, quite frankly, I'm at a > loss for ways to investigate this problem. I would appreciate any help this > list could provide.
In general I think it's safe to say that everyone will see some occasional "invalid" drops of individual packets. However that shouldn't lead to killed/timed out connections, so something seems to be up. It's hard to say what's causing it though. Netfilter has a number of reasons to mark a packet with state invalid. "Possible states are INVALID meaning that the packet could not be identified for some reason which includes running out of memory and ICMP errors which don't correspond to any known connection" (http://lists.netfilter.org/pipermail/netfilter-devel/2003-June/011860.html) You can try the following workarounds: - If you're using Vuurmuur 0.8 beta2 you can disable the dropping of invalid packets - you can try telling conntrack to be more "liberal" by setting: "echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal" (http://lists.netfilter.org/pipermail/netfilter/2006-September/066840.html) I think it would be interesting to inspect whats really happening on the wire though, using a tool like wireshark or tcpdump you can maybe uncover whats really causing this. Cheers, Victor ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Vuurmuur-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/vuurmuur-users
