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 <n...@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.


_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to