[Swan] Basic firewall rules for traffic through tunnel

Nick Howitt nick at howitts.co.uk
Tue Apr 3 11:30:33 UTC 2018


Hi Tuomo,
Thanks. Replies are in-line. The devs have realised the existing rules 
are old/legacy and need revisiting. I am just investigating to see if I 
can get ahead of the game.
Nick

On 03/04/2018 08:13, Tuomo Soini wrote:
> 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.
I can push for a change here. I am just working with what I have 
currently trying to make minimal intervention to the firewall.
>
>>      iptables -I FORWARD -s my_LAN_interface -j ACCEPT    # general
>> allow all traffic from LAN out
> That matches both ipsec and non-ipsec traffic.
Good so no "pol ipsec dir out" should be needed in the FORWARD chain.
>
>>      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.
Yes, that is the intention
>
>>      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.
My bad. The firewall rules are not held as "iptables" commands so I am 
transcribing from "iptables -nvL". There is no NEW it was a copy and 
paste error and "p-" should have been "-p" so the lines should have read:

     iptables -I INPUT -s my_WAN_interface -m state --state RELATED,ESTABLISHED -p tcp -m multiport --dports 1024:65535 -j ACCEPT
     iptables -I INPUT -s my_WAN_interface -m state --state RELATED,ESTABLISHED -p udp -m multiport --dports 1024:65535 -j ACCEPT

I guess the key thing here is that Related and Established to low ports are not allowed in by default. I am proposing that it will be covered by the "pol ipsec dir in" rule below.

>
>> 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.
Good. I hoped they would do the same as long as it is impossible for 
"pol ipsec" to arrive from the proper WAN interface.
>
>> 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.
The only place RELATED,ESTABLISHED states are not allowed is in the 
INPUT chain where low ports are blocked, the "pol ipsec" rule should 
cover that. All OUTPUT and FORWARD out traffic is allowed and all 
FORWARD in, related and established is also allowed by generic rules

I wonder why a person is reporting lost connections. I'll have a look 
and see if his whole tunnel is dropping.
>



More information about the Swan mailing list