I haven't had that problem in quite a while. Don't really remember how I fixed
it.
How do you define your IPSEC endpoint in zones:
siteA ipsec mss=1376
gives an iptables entry in 'Chain lan4_frwd':
0 0 lan4-siteA all -- * ccast 0.0.0.0/0
192.168.64.0/23 policy match dir out pol ipsec
(ccast is internet interface). So if the policy is not IPSEC it falls thru to
the
other rules.
Bill
On 10/13/2017 11:55 AM, Dorian Kind wrote:
Bill,
great idea to use shorewall-hosts, thanks for the inspiration!
There's still the issue of packets addressed to $ipsec_net leaving the
external interface unencrypted when the IPsec SA isn't present, if I
understand correctly.
Best regards,
Dorian
On 13 October 2017 at 12:21, Bill Shirley
<[email protected]> wrote:
Here's what I use:
/etc/shorewall/params:
lan4_net=192.168.4.0/24
wifi_net=192.168.6.0/24
local_net=$lan4_net,$wifi_net
RFC1918=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
zones:
# all RFC 1918 that we're not using
r1918 ipv4
hosts:
r1918 $LAN4_IF:$RFC1918!$local_net,$ipsec_net,$ovpn_net
r1918 $WIFI_IF:$RFC1918!$local_net,$ipsec_net,$ovpn_net
inet $INET1_IF:!$RFC1918
inet $INET2_IF:!$RFC1918
policy:
r1918 fw REJECT notice
lan4 r1918 REJECT info
r1918 lan4 REJECT notice
wifi r1918 REJECT notice
r1918 wifi REJECT notice
r1918 inet DROP warning
Bill
On 10/13/2017 4:53 AM, Dorian Kind wrote:
Hi all,
I'm a happy shorewall user since 2009 and never had an issue that I
couldn't solve using the excellent documentation. There's just one thing
that always bugged me. We have a couple of tunnels to branch offices, for
which shorewall inserts the appropriate iptables rules (webr being the local
zone, while the *pn zones are connected over IPsec tunnels):
Chain webr_frwd (1 references)
pkts bytes target prot opt in out source destination
[...]
759K 121M webr2gvapn all -- * eth-ext1 0.0.0.0/0
<http://0.0.0.0/0> 10.50.0.0/16 <http://10.50.0.0/16> policy match
dir out pol ipsec
6660K 4097M webr2swlpn all -- * eth-ext1 0.0.0.0/0
<http://0.0.0.0/0> 10.60.0.0/16 <http://10.60.0.0/16> policy match
dir out pol ipsec
18M 66G webr2fnopn all -- * eth-ext1 0.0.0.0/0
<http://0.0.0.0/0> 10.70.0.0/16 <http://10.70.0.0/16> policy match
dir out pol ipsec
4961K 6804M webr2hyppn all -- * eth-ext1 0.0.0.0/0
<http://0.0.0.0/0> 10.80.0.0/16 <http://10.80.0.0/16> policy match
dir out pol ipsec
99227 134M webr2rwvpn all -- * eth-ext1 0.0.0.0/0
<http://0.0.0.0/0> 10.100.0.0/16 <http://10.100.0.0/16> policy match
dir out pol ipsec
However, in order to prevent local traffic from leaking out when the IPsec
SA can't be established for some reason, I use a script to insert the
following two rules after shorewall has generated its ruleset--because per
policy, local (webr) traffic to the internet is allowed:
iptables -I OUTPUT -d 10.0.0.0/8 <http://10.0.0.0/8> --out-interface
eth-ext1 -m policy --pol none --dir out -j REJECT --reject-with
icmp-admin-prohibited
iptables -I FORWARD -d 10.0.0.0/8 <http://10.0.0.0/8> --out-interface
eth-ext1 -m policy --pol none --dir out -j REJECT --reject-with
icmp-admin-prohibited
I would really like to integrate these rules into the shorewall
configuration, but can't figure out any way to do it. From what I can tell,
shorewall-rules does not have policy match options.
Is there a canonical way to prevent RFC1918-addressed, non IPsec encrypted
packets from leaving the FW on an external interface?
Thanks and best regards,
Dorian
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
