[Swan] Basic firewall rules for traffic through tunnel

[Tuomo Soini]

On Mon, 2 Apr 2018 09:06:29 +0100
Nick Howitt <nick at howitts.co.uk> wrote:

> Hi Paul,
> 
> ClearOS comes with the following automatic rules to allow traffic to 
> pass through the tunnel using packet marking:
> 
>     iptables -I PREROUTING -t mangle -p esp -j MARK --set-mark 0x64
>     iptables -I INPUT -m mark --mark 0x64 -d my_wan_IP -j ACCEPT    #
>     necessary for incoming traffic
>     iptables -I INPUT -m mark --mark 0x64 -d my_LAN_IP -j ACCEPT    #
>     not too sure why needed
>     iptables -I FORWARD -m mark --mark 0x64 -j ACCEPT
> 

Wow. That is /legacy/. From times when kernel didn't have netfilter
policy matching module.

> It also has the following relevant rules
> 
>     iptables -I POSTROUTING -t nat -m policy --dir out --pol ipsec -j
>     ACCEPT

This one looks kind of reverse. My guess is this is ment to be
exception for not to SNAT/MASQUERADE ipsec traffic but it would be much
better to apply -m policy --dir out --pol none to SNAT/MASQURADE rules
so order wouldn't be that important.

>     iptables -I FORWARD -s my_LAN_interface -j ACCEPT    # general
> allow all traffic from LAN out

That matches both ipsec and non-ipsec traffic.

>     iptables -I INPUT -s my_LAN_interface -j ACCEPT    # general allow
>     all traffic from LAN into server    #not sure if relevant

That does exactly what documented - I can't guess if that is relevant
or not - use case matters.

>     iptables -I OUTPUT -s my_WAN_interface -j ACCEPT    # general
> allow all traffic from WAN out
>     iptables -I OUTPUT -s my_LAN_interface -j ACCEPT    # general
> allow all traffic from LAN i/f out

No restriction to firewall generated traffic - if that is what you want
then this is the way to do it.

>     iptables -I INPUT -s my_WAN_interface -m state --state NEW
>     RELATED,ESTABLISHED p- tcp -m multiport --dports 1024:65535 -j
>     ACCEPT    # not sure if relevant to tunnel
>     iptables -I INPUT -s my_WAN_interface -m state --state NEW
>     RELATED,ESTABLISHED p- udp -m multiport --dports 1024:65535 -j
>     ACCEPT    # not sure if relevant to tunnel

Netfilter won't allo these two rules because they are not valid - I
guess you wanted "-p".

These are badly designed imho. They allow NEW states to all >1023
ports. So no firwalling at all - and that's from your WAN so this is
completely open firewall.

> 
> I am looking to replace the packet marked rules with generic policy 
> based rules which don't need to know anything about the remote end
> such as subnets, so using:
> 
>     iptables -I INPUT -m policy --dir in --pol ipsec  -j ACCEPT
>     iptables -I FORWARD -m policy --dir in --pol ipsec  -j ACCEPT

That is more generic than those marking tricks and do same.

> Am I going down the right lines or have I missed something. I have 
> someone testing it out a bit and is reporting random timeouts
> connecting to his mail server and "Random timeouts connecting to
> websites (DNS Resolution errors)".
> 
> Have I missed anything? Do also I need policy rules for outbound 
> traffic, so:
> 
>     iptables -I INPUT -m policy --dir out --pol ipsec -j ACCEPT    #
>     Also would allow low ports
>     iptables -I FORWARD -m policy --dir out --pol ipsec  -j ACCEPT
> # covered by the generic FORWARD rule?
>     iptables -I OUTPUT -m policy --dir out --pol ipsec -j ACCEPT    #
>     covered by the generic OUTPUT rule?

If your generic rules won't cover outbound ipsec secured traffic you
need these. Generally: Nobody can judge your firewalling rules without
seeing real ones. Unfortunately designing whole firewall is really out
of our scope here.

> 
> or are they irrelevant. Would they even work because I don't know
> where in the processing the packets get policy marked?

That's deep inside netfilter - that is totally automatic and you don't
need to handle that manually.

I guess your problem is you don't allow RELATED,ESTABLISHED states to
all directions - that's what real firewall design includes, so that
response packets can come back from destinations you allow those to
pass. You'd need to allow those in INPUT, FORWARD and OUTPUT chains.

-- 
Tuomo Soini <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>