Re: [Vuurmuur-users] Ping being dropped while all rules seem to say ALLOW

[Victor J. <vi...@vu...>]

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