Bas Rijniersce wrote: > Hello, > > The situation: > 192.168.1.x = India office LAN > 192.168.1.1 = Linux firewall with Vuurmuur and OpenSwan for VPN > 192.168.1.2 = Server > > 192.168.70.x = Vancouver office LAN > 192.168.70.1 = Linux firewall with Vuurmuur > 192.168.70.29 = My workstation > > There is a VPN between Mumbai and Vancouver. On the India side that > comes in via interface ipsec0 > > When I ping from Mumbai (server) to Vancouver (workstation) I see.. > > Apr 19 23:17:46 INAKFW001 kernel: vrmr: ACCEPT IN=eth0 OUT=ipsec0 > SRC=192.168.1.2 DST=192.168.70.29 LEN=60 TOS=0x00 PREC=0x00 TTL=127 > ID=58266 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=27425 > > Apr 19 23:17:46 INAKFW001 kernel: vrmr: DROP fw policy IN=ipsec0 > OUT=eth0 SRC=192.168.70.29 DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 > TTL=125 ID=34743 PROTO=ICMP TYPE=0 CODE=0 ID=512 SEQ=27425 > > In the logview interface that shows as ping and ping reply. As you can > see the timestamp is within one second. Rule that should allow this traffic: > > # rule 28: Accept service any from WSBAS.Main.Vancouver_Zone to > Main.LAN_Zone options log,loglimit="20" > /sbin/iptables -t filter -A FORWARD -i ipsec0 -o eth0 -s > 192.168.70.29/255.255.255.255 -d 192.168.1.0/255.255.255.0 -m state > --state NEW -j LOG --log-prefix "vrmr: ACCEPT " --log-level debug > /sbin/iptables -t filter -A FORWARD -i ipsec0 -o eth0 -s > 192.168.70.29/255.255.255.255 -d 192.168.1.0/255.255.255.0 -m state > --state NEW -j NEWACCEPT > > # rule 29: Accept service any from Main.Vancouver_Zone to Main.LAN_Zone > options log,loglimit="20" > /sbin/iptables -t filter -A FORWARD -i ipsec0 -o eth0 -s > 192.168.70.0/255.255.255.0 -d 192.168.1.0/255.255.255.0 -m state > --state NEW -j LOG --log-prefix "vrmr: ACCEPT " --log-level debug > /sbin/iptables -t filter -A FORWARD -i ipsec0 -o eth0 -s > 192.168.70.0/255.255.255.0 -d 192.168.1.0/255.255.255.0 -m state > --state NEW -j NEWACCEPT > > Rule 29 is for testing > > What could be the cause. Are the SEQ nr's supposed to be the same?
Hi Bas, I think the sequence numbers are supposed to be the same, yes. When looking at your logs, it looks like the icmp echo request is accepted, however not by rule 28 or 29. Both these rules have -i ipsec0 and -o eth0. The request is in the opposite direction: IN=eth0 OUT=ipsec0 The reply should have the conntrack state 'ESTABLISHED' and thus rule 28 and 29 won't match for the reply either, since they match only on state NEW. What seems to be happening here is that for some reason the icmp echo reply is not marked ESTABLISHED by conntrack and therefore not accepted automatically by the Vuurmuur ruleset. You should add some manual iptables logging rules to confirm this: iptables -I FORWARD 1 -p icmp --icmp-type echo-reply -m state --state NEW -j LOG --log-prefix "echo reply state NEW" iptables -I FORWARD 1 -p icmp --icmp-type echo-reply -m state --state ESTABLISHED -j LOG --log-prefix "echo reply state EST" iptables -I FORWARD 1 -p icmp --icmp-type echo-reply -m state --state RELATED -j LOG --log-prefix "echo reply state REL" If it is not ESTABLISHED, there seems to be something wrong in conntrack and/or the vpn. Let me know the results! Cheers, Victor ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Vuurmuur-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/vuurmuur-users
