On Sun, 2004-11-21 at 17:46, BjÃrn Schmidt wrote: > I changed the log rule(s) that creates "ILLEGAL_PACKET", now it creates > "OUTPUT_INVALID", "INPUT_INVALID" and "FORWARD_INVALID". Here is one line > from the log with the new rules (client): > > Nov 21 23:21:43 gigabyte OUTPUT_INVALID IN= OUT=eth0 MAC= SRC=192.168.1.2 > DST=192.168.1.1 LEN=52 TOS=00 PREC=0x00 TTL=64 ID=23692 DF PROTO=TCP SPT=32807 > DPT=22 SEQ=798630945 ACK=685050669 WINDOW=1460 ACK URGP=0 > > The state of this packet should be ESTABLISHED, but it _is_ INVALID. > Perhaps there is a bug in ipsec or netfilter... it almost seems like you have an asymmetric routing situation--what i mean by that is that the SYN packet is reaching 192.168.1.2 without going through the firewall and therefore the SYN-ACK is NEW, not RELATED... also--you keep mentioning IPsec. first off--i never use conntrack to match IPsec traffic. second--you need to be aware that packets traverse the filter chains twice in a 2.6 kernel--once encrypted, and once decrypted. for 2.6 IPsec rules, i use something like: # mark ipsec traffic iptables -t mangle -A PREROUTING -p 50 -s $PEER -j MARK --set-mark 1 # allow IKE & ESP in iptables -A INPUT -p udp -s $PEER --sport 500 --dport 500 -j ACCEPT iptables -A INPUT -p 50 -s $PEER -j ACCEPT # allow decrypted packets iptables -A INPUT -m mark --mark 1 -j ACCEPT # allow IKE & ESP out iptables -A OUTPUT -p udp -d $PEER --sport 500 --dport 500 -j ACCEPT iptables -A OUTPUT -p 50 -d $PEER -j ACCEPT [ your sepcific rules follow here ] > > my guess is that your rules do not match your intentions. > > Impossible. I have this problem even with this _minimalistic_ ruleset: > > gigabyte:~# cat firewall.tmp > #!/bin/sh > > iptables -P INPUT DROP > iptables -P OUTPUT DROP > iptables -P FORWARD DROP > > iptables -A INPUT -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT > iptables -A OUTPUT -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT > iptables -A FORWARD -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT > > iptables -A INPUT -m state --state INVALID -j ULOG --ulog-prefix INPUT_INVALID > iptables -A OUTPUT -m state --state INVALID -j ULOG --ulog-prefix OUTPUT_INVALID > iptables -A FORWARD -m state --state INVALID -j ULOG --ulog-prefix FORWARD_INVALID > > >>Besides I forgot to mention that i only get "false INVALID" states with > >>activated IPsec (esp in transport mode, kernel 2.6). With IPsec _AND_ iptables > >>it es NOT possible to establish a new tcp connection due to these "INVALID > >>state packets". > > > > uh huh... post your rules: > > > > iptables -t mangle -vnxL > > gigabyte:~# iptables -t mangle -vnxL > Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > > Chain INPUT (policy ACCEPT 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > > Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > > Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > > Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > > > > iptables -t nat -vnxL > > gigabyte:~# iptables -t nat -vnxL > Chain PREROUTING (policy ACCEPT 7 packets, 1515 bytes) > pkts bytes target prot opt in out source > destination > > Chain POSTROUTING (policy ACCEPT 26 packets, 2637 bytes) > pkts bytes target prot opt in out source > destination > > Chain OUTPUT (policy ACCEPT 26 packets, 2565 bytes) > pkts bytes target prot opt in out source > destination > > > iptables -vnxL > > gigabyte:~# iptables -vnxL > Chain INPUT (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > 2460 2616788 ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 state NEW,RELATED,ESTABLISHED > 0 0 ULOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 state INVALID ULOG copy_range 0 nlgroup 1 prefix > `INPUT_INVALID' queue_threshold 1 > > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 state NEW,RELATED,ESTABLISHED > 0 0 ULOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 state INVALID ULOG copy_range 0 nlgroup 1 prefix > `FORWARD_INVALID' queue_threshold 1 > > Chain OUTPUT (policy DROP 38 packets, 2036 bytes) > pkts bytes target prot opt in out source > destination > 1938 959688 ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 state NEW,RELATED,ESTABLISHED > 38 2036 ULOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 state INVALID ULOG copy_range 0 nlgroup 1 prefix > `OUTPUT_INVALID' queue_threshold 1 the only packet counters that are incrementing are the OUTPUT chain filters... so for *some* reason--you have packets that are leaking through that first rule... > Hmmm, it is not possible to establish a ssh connection, but it IS > possible to establish a telnet connection (but it needs ~148 seconds > until the "skyron login:" appears). sounds like a reverse name lookup issue. can you provide a tcpdump (from 192.168.1.2) of a connection attempt? -j -- "Weaseling out of things is important to learn. It's what separates us from the animals...except the weasel." --The Simpsons
