[Shorewall-users] shorewall and Strongswan - possible incompatibility?

[John Depp]

Hello everyone!
I'm using Debian, Shorewall and Stongswan on my linux routers.
It seems Shorewall don't allow input of ESP packets, formed by ipsec
initiated by Strongswan.

I have the following line tunnels:

#TYPE ZONE GATEWAY GATEWAY_ZONE
ipsec net xx.xx.xx.51

it compiles to the following iptables rules:

...
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
107 28045 eth0_in all -- eth0 * 0.0.0.0/0
0.0.0.0/0
...
Chain eth0_in (1 references)
pkts bytes target prot opt in out source
destination
...
101 27583 net-fw all -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir in pol none
...
Chain net-fw (1 references)
pkts bytes target prot opt in out source
destination
12 2213 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT esp -- * * xx.xx.xx.51 0.0.0.0/0

0 0 ACCEPT udp -- * * xx.xx.xx.51 0.0.0.0/0
udp dpt:500 ctstate NEW,UNTRACKED

And the packets never hit the net-fw chain, rejected by policy:
Nov 28 12:24:47 gw kernel: [9640691.231945] Shorewall:INPUT:REJECT:IN=eth0
OUT= MAC=00: SRC=xx.xx.xx.51 DST=<router> LEN=86 TOS=0x00 PREC=0x00 TTL=62
ID=61247 PROTO=4

In the case I use the "leftfirewall=yes" option in Strongswan config, which
inserts it's native iptables rules, it inserts the following:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
...
0 0 ACCEPT 4 -- eth0 * xx.xx.xx.51 <router>
policy match dir in pol ipsec reqid 2 proto 50

So I assume there should be no "policy match dir in pol none" option in
eth0_in chain to correctly process ipsec packets.
Similarly, if I add some rules like
ACCEPT net:xx.xx.xx.0/16 $FW ah
ACCEPT net:xx.xx.xx.0/16 $FW esp
packets never hit those rules too as they are compiled into net-fw chain.

So, is there any option to turn off "policy match dir in pol none" option
in eth0_in chain or am I completely mistaken of the issue?

Thanks in advance!

[Bill Shirley]

Try type ipsec in your zones file:
#ZONE TYPE OPTIONS IN OUT
sfn ipv4

It generates:
0 0 fw-sfn all -- * * 0.0.0.0/0 192.168.4.0/24 policy match dir out pol ipsec

Bill

Post by John Depp
Hello everyone!
I'm using Debian, Shorewall and Stongswan on my linux routers.
It seems Shorewall don't allow input of ESP packets, formed by ipsec initiated by Strongswan.
#TYPE ZONE GATEWAY GATEWAY_ZONE
ipsec net xx.xx.xx.51
...
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
107 28045 eth0_in all -- eth0 * 0.0.0.0/0 <http://0.0.0.0/0> 0.0.0.0/0 <http://0.0.0.0/0>
...
Chain eth0_in (1 references)
pkts bytes target prot opt in out source destination
...
101 27583 net-fw all -- * * 0.0.0.0/0 <http://0.0.0.0/0> 0.0.0.0/0 <http://0.0.0.0/0> policy match dir
in pol none
...
Chain net-fw (1 references)
pkts bytes target prot opt in out source destination
12 2213 ACCEPT all -- * * 0.0.0.0/0 <http://0.0.0.0/0> 0.0.0.0/0 <http://0.0.0.0/0> ctstate
RELATED,ESTABLISHED
0 0 ACCEPT esp -- * * xx.xx.xx.51 0.0.0.0/0 <http://0.0.0.0/0>
0 0 ACCEPT udp -- * * xx.xx.xx.51 0.0.0.0/0 <http://0.0.0.0/0> udp dpt:500 ctstate NEW,UNTRACKED
Nov 28 12:24:47 gw kernel: [9640691.231945] Shorewall:INPUT:REJECT:IN=eth0 OUT= MAC=00: SRC=xx.xx.xx.51 DST=<router> LEN=86
TOS=0x00 PREC=0x00 TTL=62 ID=61247 PROTO=4
In the case I use the "leftfirewall=yes" option in Strongswan config, which inserts it's native iptables rules, it inserts the
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
...
0 0 ACCEPT 4 -- eth0 * xx.xx.xx.51 <router> policy match dir in pol ipsec reqid 2 proto 50
So I assume there should be no "policy match dir in pol none" option in eth0_in chain to correctly process ipsec packets.
Similarly, if I add some rules like
ACCEPT net:xx.xx.xx.0/16 $FW ah
ACCEPT net:xx.xx.xx.0/16 $FW esp
packets never hit those rules too as they are compiled into net-fw chain.
So, is there any option to turn off "policy match dir in pol none" option in eth0_in chain or am I completely mistaken of the
issue?
Thanks in advance!
------------------------------------------------------------------------------
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

------------------------------------------------------------------------------

[Bill Shirley]

Arrg, sorry:
#ZONE TYPE OPTIONS IN OUT
sfn ipsec

Bill

Post by Bill Shirley
#ZONE TYPE OPTIONS IN OUT
sfn ipv4
0 0 fw-sfn all -- * * 0.0.0.0/0 192.168.4.0/24 policy match dir out pol ipsec
Bill

Post by John Depp
Hello everyone!
I'm using Debian, Shorewall and Stongswan on my linux routers.
It seems Shorewall don't allow input of ESP packets, formed by ipsec initiated by Strongswan.
#TYPE ZONE GATEWAY GATEWAY_ZONE
ipsec net xx.xx.xx.51
...
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
107 28045 eth0_in all -- eth0 * 0.0.0.0/0 <http://0.0.0.0/0> 0.0.0.0/0 <http://0.0.0.0/0>
...
Chain eth0_in (1 references)
pkts bytes target prot opt in out source destination
...
101 27583 net-fw all -- * * 0.0.0.0/0 <http://0.0.0.0/0> 0.0.0.0/0 <http://0.0.0.0/0> policy match dir
in pol none
...
Chain net-fw (1 references)
pkts bytes target prot opt in out source destination
12 2213 ACCEPT all -- * * 0.0.0.0/0 <http://0.0.0.0/0> 0.0.0.0/0 <http://0.0.0.0/0> ctstate
RELATED,ESTABLISHED
0 0 ACCEPT esp -- * * xx.xx.xx.51 0.0.0.0/0 <http://0.0.0.0/0>
0 0 ACCEPT udp -- * * xx.xx.xx.51 0.0.0.0/0 <http://0.0.0.0/0> udp dpt:500 ctstate NEW,UNTRACKED
Nov 28 12:24:47 gw kernel: [9640691.231945] Shorewall:INPUT:REJECT:IN=eth0 OUT= MAC=00: SRC=xx.xx.xx.51 DST=<router> LEN=86
TOS=0x00 PREC=0x00 TTL=62 ID=61247 PROTO=4
In the case I use the "leftfirewall=yes" option in Strongswan config, which inserts it's native iptables rules, it inserts the
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
...
0 0 ACCEPT 4 -- eth0 * xx.xx.xx.51 <router> policy match dir in pol ipsec reqid 2 proto 50
So I assume there should be no "policy match dir in pol none" option in eth0_in chain to correctly process ipsec packets.
Similarly, if I add some rules like
ACCEPT net:xx.xx.xx.0/16 $FW ah
ACCEPT net:xx.xx.xx.0/16 $FW esp
packets never hit those rules too as they are compiled into net-fw chain.
So, is there any option to turn off "policy match dir in pol none" option in eth0_in chain or am I completely mistaken of the
issue?
Thanks in advance!
------------------------------------------------------------------------------
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

------------------------------------------------------------------------------
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

------------------------------------------------------------------------------

[John Depp]

I do have ipsec zone, and it compiles to rules all right:
5 380 vpnpx-fw all -- * * 192.168.0.0/16 0.0.0.0/0
policy match dir in pol ipsec mode tunnel
it's external IPs and ESP packets I have trouble with.
Thank you.

2016-11-28 16:07 GMT+03:00 Bill Shirley <

Post by Bill Shirley
#ZONE TYPE OPTIONS IN OUT
sfn ipv4
0 0 fw-sfn all -- * * 0.0.0.0/0
192.168.4.0/24 policy match dir out pol ipsec
Bill

Post by John Depp
Hello everyone!
I'm using Debian, Shorewall and Stongswan on my linux routers.
It seems Shorewall don't allow input of ESP packets, formed by ipsec

initiated by Strongswan.

Post by John Depp
#TYPE ZONE GATEWAY GATEWAY_ZONE
ipsec net xx.xx.xx.51
...
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source

destination

Post by John Depp
107 28045 eth0_in all -- eth0 * 0.0.0.0/0 <http://0.0.0.0/0>

0.0.0.0/0 <http://0.0.0.0/0>

Post by John Depp
...
Chain eth0_in (1 references)
pkts bytes target prot opt in out source

destination

Post by John Depp
...
101 27583 net-fw all -- * * 0.0.0.0/0 <http://0.0.0.0/0>

0.0.0.0/0 <http://0.0.0.0/0> policy match dir

Post by John Depp
in pol none
...
Chain net-fw (1 references)
pkts bytes target prot opt in out source

destination

Post by John Depp
12 2213 ACCEPT all -- * * 0.0.0.0/0 <http://0.0.0.0/0>

0.0.0.0/0 <http://0.0.0.0/0> ctstate

Post by John Depp
RELATED,ESTABLISHED
0 0 ACCEPT esp -- * * xx.xx.xx.51 0.0.0.0/0 <

http://0.0.0.0/0>

Post by John Depp
0 0 ACCEPT udp -- * * xx.xx.xx.51 0.0.0.0/0 <

http://0.0.0.0/0> udp dpt:500 ctstate NEW,UNTRACKED

Post by John Depp
Nov 28 12:24:47 gw kernel: [9640691.231945]

Shorewall:INPUT:REJECT:IN=eth0 OUT= MAC=00: SRC=xx.xx.xx.51 DST=<router>
LEN=86

Post by John Depp
TOS=0x00 PREC=0x00 TTL=62 ID=61247 PROTO=4
In the case I use the "leftfirewall=yes" option in Strongswan config,

which inserts it's native iptables rules, it inserts the

Post by John Depp
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source

destination

Post by John Depp
...
0 0 ACCEPT 4 -- eth0 * xx.xx.xx.51 <router>

policy match dir in pol ipsec reqid 2 proto 50

Post by John Depp
So I assume there should be no "policy match dir in pol none" option in

eth0_in chain to correctly process ipsec packets.

Post by John Depp
Similarly, if I add some rules like
ACCEPT net:xx.xx.xx.0/16 $FW ah
ACCEPT net:xx.xx.xx.0/16 $FW esp
packets never hit those rules too as they are compiled into net-fw chain.
So, is there any option to turn off "policy match dir in pol none"

option in eth0_in chain or am I completely mistaken of the

Post by John Depp
issue?
Thanks in advance!
------------------------------------------------------------

------------------

Post by John Depp
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

------------------------------------------------------------
------------------
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello everyone! I'm using Debian, Shorewall and Stongswan on my
linux routers. It seems Shorewall don't allow input of ESP packets,
formed by ipsec initiated by Strongswan.
#TYPE ZONE GATEWAY GATEWAY_ZONE ipsec
net xx.xx.xx.51
... Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target
prot opt in out source destination 107 28045 eth0_in all
-- eth0 * 0.0.0.0/0 <http://0.0.0.0/0>
0.0.0.0/0 <http://0.0.0.0/0> ... Chain eth0_in (1 references) pkts
bytes target prot opt in out source destination
... 101 27583 net-fw all -- * * 0.0.0.0/0
<http://0.0.0.0/0> 0.0.0.0/0 <http://0.0.0.0/0>
policy match dir in pol none ... Chain net-fw (1 references) pkts
bytes target prot opt in out source destination
12 2213 ACCEPT all -- * * 0.0.0.0/0
<http://0.0.0.0/0> 0.0.0.0/0 <http://0.0.0.0/0>
ctstate RELATED,ESTABLISHED 0 0 ACCEPT esp -- * *
xx.xx.xx.51 0.0.0.0/0 <http://0.0.0.0/0> 0 0 ACCEPT udp --
* * xx.xx.xx.51 0.0.0.0/0 <http://0.0.0.0/0>
udp dpt:500 ctstate NEW,UNTRACKED
And the packets never hit the net-fw chain, rejected by policy: Nov
28 12:24:47 gw kernel: [9640691.231945]
Shorewall:INPUT:REJECT:IN=eth0 OUT= MAC=00: SRC=xx.xx.xx.51
DST=<router> LEN=86 TOS=0x00 PREC=0x00 TTL=62 ID=61247 PROTO=4
In the case I use the "leftfirewall=yes" option in Strongswan
config, which inserts it's native iptables rules, it inserts the
following: Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes
target prot opt in out source destination ... 0 0
ACCEPT 4 -- eth0 * xx.xx.xx.51 <router>
policy match dir in pol ipsec reqid 2 proto 50
So I assume there should be no "policy match dir in pol none"
option in eth0_in chain to correctly process ipsec packets.
Similarly, if I add some rules like ACCEPT net:xx.xx.xx.0/16
$FW ah ACCEPT net:xx.xx.xx.0/16 $FW
esp packets never hit those rules too as they are compiled into
net-fw chain.
So, is there any option to turn off "policy match dir in pol none"
option in eth0_in chain or am I completely mistaken of the issue?

Do you have nested tunnels here? Normally, ESP packets would not
themselves require 'pol ipsec'.

- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJYPGRTAAoJEJbms/JCOk0QkPwP+gMPp9wvgI+k2Uju679BES09
gz8r5yPXPgvyrrSAlS60w6rLAmhOabcbQt36avodjUWf7CpR+RQPscd9K2dmhqRm
pkUzOfKBqqjkxFSpQnVkju6nJz1oJENa4SAZapjVGYG1czGyDa+FTSaIXkL4+IbH
trEkNQLXdQkLyANXEnH36J5k2HUsgRjg6kKqOMh048c6cAJC8u46NbO1Fl/X6DUs
cJTT/E17W66AiyLohjBpCPednqmizLj0ScfHKAysvlRWgdV9/rEMyzWs3B0ZLKqz
oBOuHJBz/qdKtur19fqvffp8gGPEYtX3z9xdu7AmLjvTO89PIdrractc/y5fkB8j
xq4kIo1JzWs0pbsBEcQXMruW+RY49dGQzSmJDgkBllyjba5h50+nVD2tA8DgnfYV
1eG09Kss/5nc7qHfwCem3cWwnpykdK7s0P/WLuLHVV3r/EzIOlyt/LBM7iRUkJiZ
gwXqoe9nZ+5zNueN4Y8ykLZHXDvzT7XTtHWLmnCQy30XkqXTRajc0eW4m5rN+zng
ooBoYbJJiPKWeQIyNVlCj0PjNx9cbvqXct6fBvY8aJVyu3dbVi7NvHeRrj6VI8j6
0Kc3aXropAhYODsBkpIJFC0oJvJJS8yfHHB40g8arJ9bH0sc655slOYYB/elRwdV
idTWROgT/q0ls2FUSY1C
=uQj2
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------

[Tom Eastep]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Tom Eastep
Do you have nested tunnels here? Normally, ESP packets would not
themselves require 'pol ipsec'.

It would probably be most useful if you would forward to me personally
the output of 'shorewall dump'. That way, I can see both your
Shorewall and IPSEC configurations.

Thanks,
- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJYPHU0AAoJEJbms/JCOk0QwzMP/iTS6e41E+Hv0Q5DbxaoWwOc
Pra2Ovfw11brW3omlZBBXITpHETnxAKKDvLJCbP59kAoGTa7LdonCDqTRQpEhP7A
wbQsMQ+xMI4p7JDtydB7JgdiDtKVRiNCil2bmB92IpgcOeRDKZ/mgmyIFUsxg6iO
mVP4RcB7kFqvzNU8Ysz8M2srMuElwNPzbBvdyEPnwrPTcycffN21W6l3w1bsml5q
EsPAuTMlmxcZsV3Ki0HDXRBhKSkpCskqVgZXedm4wFlWye6F0edvH/5BGNtPOSsd
EixlASv+yVMM2JulgRJ0/WJbqLTrXTVS4XOxcM7r/eJnAFotqriYV2CjYOWt4iOk
qKFO9JB6R6ovwRiE2xhNT6l75OK+TZbMlywzDPkFly9X/T1X5RKWiYeDCmW/xbwK
cuByj7zoI7lKDgqe9GmoJ7RW5/Gicoo9XkogStX0lKI5chYmKsX3GE274UIakcGM
mi+jMaXcOkKb+JMydw6zLSJKcruS72zmZe8re/6W3HEDGGUzMltU/bJZwUNH4tii
mFgbxXy8UxuqubpjtbjsGmOSGZLby8Gjgcu1m0z3Wpgx50iOUXxSXGS1saRroLEu
/5Sd6aiDm57nXdgsxXv3slLdkfdiJTnEUIF2XluGeNhtHTZNXKWeieHD0/bv6DIs
vT+hCu1PUb4MU2HJ8tI2
=0Pwt
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------

[Tom Eastep]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Tom Eastep

Post by Tom Eastep
Do you have nested tunnels here? Normally, ESP packets would not
themselves require 'pol ipsec'.

It would probably be most useful if you would forward to me
personally the output of 'shorewall dump'. That way, I can see both
your Shorewall and IPSEC configurations.

I took another look at your report, and it looks like there is IPIP
encapsulation occurring (PROTO 4, in the netfilter log entry). So
again, it looks like there is some sort of nested tunneling occurring.

- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJYPgAzAAoJEJbms/JCOk0QBi0P/0Y+lg1bIdygF3f86wJEZ9dr
8Q5LhqagYKPPfjaGxItkwLO/fTFN6c2dVNHIqP7JeznMmpHE9VhoOCm5kPaJZfDf
L5WuP3GULGDNKNMyQGEbvCrCmrblEDGi4l7+Qs88FTEWztEB2/UkBMOGwxLOhswh
b47gosSmT1DANbpDsbAhFTIDlCdjBSK8j8HdjRhC2tXe0AS1JZrsMwy5lqEKU0UK
j5TqompEvQkBFxk42lewbL55wTwZvOiJAsehT6uSh5oy/CEY5KeZpvC0rJsSQ6J1
w/OjpHMl6dC1fiq4f/9PrSkLP+zPWvFgiqvi8LX0eqIqXp/nzLjeWl2YKBUMjcVB
5YI6Lyg46eWSaoOVAdR9JjIv4clZyjQ7M9nwjVCStruaPnr1yHWzHVz4jtLMcKtc
1F0+pXz//5kTnGeQ3hOxWsxaValZX70vqsSaq2Te7fBaIoj3z+cgR7U8E6Agayzl
R4/A6xMjM+dAzqLbDVeVIV0dlwCHsuUPUeDdkdBfiruiaF9KLvVLdjdaT2sD6Q+Q
NI6Cf8SOPa/LyFZ7V42oT9PzspLp/BX+YQkyOifChgX4D8bKp/zUB9KVV3M9TVxc
iBfWwo8VsPRLlnST2H+RlCntvCTAZ91zJD9b021TD5Y6m5Y5R8wZDNN9B49/vXIb
H9WaChyAMLoHZsv0PsxD
=R1NJ
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------

[John Depp]

Sorry for delay
I'm pretty sure those proto 4 IPIP is ESP packets - I was using ping for
testing and was capturing them with tshark, and they were marked ESP there.

Post by Tom Eastep
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Tom Eastep

Post by Tom Eastep
Do you have nested tunnels here? Normally, ESP packets would not
themselves require 'pol ipsec'.

It would probably be most useful if you would forward to me
personally the output of 'shorewall dump'. That way, I can see both
your Shorewall and IPSEC configurations.

I took another look at your report, and it looks like there is IPIP
encapsulation occurring (PROTO 4, in the netfilter log entry). So
again, it looks like there is some sort of nested tunneling occurring.
- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJYPgAzAAoJEJbms/JCOk0QBi0P/0Y+lg1bIdygF3f86wJEZ9dr
8Q5LhqagYKPPfjaGxItkwLO/fTFN6c2dVNHIqP7JeznMmpHE9VhoOCm5kPaJZfDf
L5WuP3GULGDNKNMyQGEbvCrCmrblEDGi4l7+Qs88FTEWztEB2/UkBMOGwxLOhswh
b47gosSmT1DANbpDsbAhFTIDlCdjBSK8j8HdjRhC2tXe0AS1JZrsMwy5lqEKU0UK
j5TqompEvQkBFxk42lewbL55wTwZvOiJAsehT6uSh5oy/CEY5KeZpvC0rJsSQ6J1
w/OjpHMl6dC1fiq4f/9PrSkLP+zPWvFgiqvi8LX0eqIqXp/nzLjeWl2YKBUMjcVB
5YI6Lyg46eWSaoOVAdR9JjIv4clZyjQ7M9nwjVCStruaPnr1yHWzHVz4jtLMcKtc
1F0+pXz//5kTnGeQ3hOxWsxaValZX70vqsSaq2Te7fBaIoj3z+cgR7U8E6Agayzl
R4/A6xMjM+dAzqLbDVeVIV0dlwCHsuUPUeDdkdBfiruiaF9KLvVLdjdaT2sD6Q+Q
NI6Cf8SOPa/LyFZ7V42oT9PzspLp/BX+YQkyOifChgX4D8bKp/zUB9KVV3M9TVxc
iBfWwo8VsPRLlnST2H+RlCntvCTAZ91zJD9b021TD5Y6m5Y5R8wZDNN9B49/vXIb
H9WaChyAMLoHZsv0PsxD
=R1NJ
-----END PGP SIGNATURE-----
------------------------------------------------------------
------------------
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tuomo Soini]

On Wed, 30 Nov 2016 13:30:46 +0300

Post by John Depp
Sorry for delay
I'm pretty sure those proto 4 IPIP is ESP packets - I was using ping
for testing and was capturing them with tshark, and they were marked
ESP there.

ipcomp causes that. If you want to allow that, you need to add
following to tunnels:

ipip vpn 0.0.0.0/0

Of course if your IPsec zone is vpn.

But I'd like to warn that many latish crypto security problems are
related to compression with encryption so I'd suggest disabling ipcomp.

Also note that usually tunnel type ipsecnat is what you want instead of
tunnel type ipsec.

[John Depp]

Thanks alot! I'll give it a try in a day or two - with ipsecnat and compression turned off also.

-----ИсхПЎМПе сППбщеМОе-----
От: "Tuomo Soini" <***@foobar.fi>
ОтправлеМП: ‎03.‎12.‎2016 14:01
КПЌу: "John Depp" <***@gmail.com>
КПпОя: "Shorewall Users" <shorewall-***@lists.sourceforge.net>
ТеЌа: Re: [Shorewall-users] shorewall and Strongswan - possibleincompatibility?

On Wed, 30 Nov 2016 13:30:46 +0300

Post by John Depp
Sorry for delay
I'm pretty sure those proto 4 IPIP is ESP packets - I was using ping
for testing and was capturing them with tshark, and they were marked
ESP there.

ipcomp causes that. If you want to allow that, you need to add
following to tunnels:

ipip vpn 0.0.0.0/0

Of course if your IPsec zone is vpn.

But I'd like to warn that many latish crypto security problems are
related to compression with encryption so I'd suggest disabling ipcomp.

Also note that usually tunnel type ipsecnat is what you want instead of
tunnel type ipsec.

[John Depp]

Ok, i've done some reconfiguration and testing.

1. I don't know how to make ipcomp work.
- Suggeted tunnels line doesn't work, as I have to allow traffic from
net, not from vpn zone
- if I use
ipip net <router address>
it still doesn't work, as it translates to rule "ACCEPT 4" (4 is proto
field) in "net-fw" chain, which is called with "ipsec pol none" option in
"eth0_in" chain
And while syslog shows it in REJECTED, proto 4, tshark shows it as ESP, so
I believe packets still don't hit the chain!

So I second my question - could I in any way remove "ipsec pol none" OR use
some combined tunnel mode "ipsec and ipip" or better yet could you add
proto 4 to proto list when compiling ipsec tunnel?

2. With ipcomp turned off, things work smoothly, thank you very much.

Could I suggest add some strongswan configuration options to shorewall
ipsec documentation, as it goes by default in debian systems?
i.e. I use:

compress = no # to disable ipcomp
leftfirewall = no # to leave shorewall manage the iptables

If you'd like to add the strongswan article, i could provide working
configs for strongswan and shorewall

And the ipcomp question stills open.

Thank you!

Post by John Depp
Thanks alot! I'll give it a try in a day or two - with ipsecnat and
compression turned off also.
------------------------------
ОтправлеМП: ‎03.‎12.‎2016 14:01
ТеЌа: Re: [Shorewall-users] shorewall and Strongswan - possibleincompatibility?
On Wed, 30 Nov 2016 13:30:46 +0300

Post by John Depp
Sorry for delay
I'm pretty sure those proto 4 IPIP is ESP packets - I was using ping
for testing and was capturing them with tshark, and they were marked
ESP there.

ipcomp causes that. If you want to allow that, you need to add
ipip vpn 0.0.0.0/0
Of course if your IPsec zone is vpn.
But I'd like to warn that many latish crypto security problems are
related to compression with encryption so I'd suggest disabling ipcomp.
Also note that usually tunnel type ipsecnat is what you want instead of
tunnel type ipsec.
--
Foobar Linux services
[phone]
Foobar Oy <http://foobar.fi/>

[Tom Eastep]

Post by John Depp
Ok, i've done some reconfiguration and testing.
1. I don't know how to make ipcomp work. - Suggeted tunnels line
doesn't work, as I have to allow traffic from net, not from vpn
zone

Not according to the log message in your original post. That log
message indicated that the message source was in *NONE* of your zones.

As I indicated in an earlier post, the fastest way for me to solve
this for you is to see the (unaltered) output of 'shorewall dump' with
the tunnel entry that Tuomo suggested to you.

- -Tom

- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[John Depp]

OK. I've got testlab installed in GNS for testing purposes, with 2 dumb
vpcs to emulate local networks, 2 virtualbox VMs with debian 8, shorewall
and strongswan:
VPC1 (10.1.1.100) --- (10.1.1.1) Router1 (10.100.0.1) --- (switch) ---
(10.100.0.2) Router2 (10.1.2.1) --- (10.1.2.100) VPC2
All networks are /24.
Routers configs are similar except IP addresses.
I've got identical behavior with virtual setup as with physical:
- ipcomp turned off, packets go throu
- ipcomp turned on, packets rejected
Here is shorewall dump from virtual Router1 with suggested ipip tunnel
option, packets still rejected, along with shorewall's ipsec.conf.
Thank you for your time and patience.

Post by Tom Eastep
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by John Depp
Ok, i've done some reconfiguration and testing.
1. I don't know how to make ipcomp work. - Suggeted tunnels line
doesn't work, as I have to allow traffic from net, not from vpn
zone

Not according to the log message in your original post. That log
message indicated that the message source was in *NONE* of your zones.
As I indicated in an earlier post, the fastest way for me to solve
this for you is to see the (unaltered) output of 'shorewall dump' with
the tunnel entry that Tuomo suggested to you.
- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJYSKjdAAoJEJbms/JCOk0QSNYQALJ9n5KOPeGr99INgFNKB7CU
L4qW/nQ2HHvlOfbjD/XNPtosP4JGQp/kChhu32m/2qyyRdV3qZVbLBIRMYQYmCV2
k57Yep+cX9VbgdDv4GyLFLnCwPkdmui7d0fkMoxhE4ibOBwIuue4vJhbdbMMz4Yd
NgxIbVLMjuAIiEiXkgP1ercwbQHoPwh7ue3kh/g902mRtdJMUfE49jD1R/5u99Q+
UBClIOJOux/PMRrRq5iIuANpH3vmgKDB5MLc4rEMEI4Qm2Uv+TwhPY7NSqJ7XXDz
l/3BgQ5+EVY9BGlu8r0tR0mKCuarSIhz3Rd2O1jdNpBk1W+NnaZ9qKvhw26dS+Y8
/Gj4Iw5VJP6n9Qzb55dnaynssdBpJnRQlAcm3YEONom654tX0UzCcQJx7MNsOhal
tuGkQacUAhssjHM3TseO+kSSBWqYuMp2Huvh6CzMBLOloRS0j+EC8dPPH4VHihf2
XY4pIC99vtJdjvAA72V/ga19G93LzsW6AFP/AQCej3urjmyMsogeBNOqmJqPTgrb
4Oup7D2WL3QFnqxJBzZ3SOZpwvIppfM1IPL66HiSm75IM7igY/xfdURfpBjTfyK7
G5BsNP2S/j1k7X/hEWHMIuFbZ4wuQAhjkVZ2M/LkFtJbh0sWr9T6u99HirxA1372
haiDkkDhju7ZwtesWwHR
=YDH+
-----END PGP SIGNATURE-----
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

Post by John Depp
OK. I've got testlab installed in GNS for testing purposes, with 2
dumb vpcs to emulate local networks, 2 virtualbox VMs with debian
8, shorewall and strongswan: VPC1 (10.1.1.100) --- (10.1.1.1)
Router1 (10.100.0.1) --- (switch) --- (10.100.0.2) Router2
(10.1.2.1) --- (10.1.2.100) VPC2 All networks are /24. Routers
configs are similar except IP addresses. I've got identical
behavior with virtual setup as with physical: - ipcomp turned off,
packets go throu - ipcomp turned on, packets rejected Here is
shorewall dump from virtual Router1 with suggested ipip tunnel
option, packets still rejected, along with shorewall's ipsec.conf.
Thank you for your time and patience.

No problem.

I need you to produce another dump collected just as this one, after
you have installed the ipsec-tools package. Without that package
installed, the dump contains no IPSEC information.

I apologize for not mentioning that earlier,

- -Tom

- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[John Depp]

Here it is!
Thank you!

Post by Tom Eastep
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by John Depp
OK. I've got testlab installed in GNS for testing purposes, with 2
dumb vpcs to emulate local networks, 2 virtualbox VMs with debian
8, shorewall and strongswan: VPC1 (10.1.1.100) --- (10.1.1.1)
Router1 (10.100.0.1) --- (switch) --- (10.100.0.2) Router2
(10.1.2.1) --- (10.1.2.100) VPC2 All networks are /24. Routers
configs are similar except IP addresses. I've got identical
behavior with virtual setup as with physical: - ipcomp turned off,
packets go throu - ipcomp turned on, packets rejected Here is
shorewall dump from virtual Router1 with suggested ipip tunnel
option, packets still rejected, along with shorewall's ipsec.conf.
Thank you for your time and patience.

No problem.
I need you to produce another dump collected just as this one, after
you have installed the ipsec-tools package. Without that package
installed, the dump contains no IPSEC information.
I apologize for not mentioning that earlier,
- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJYUCUZAAoJEJbms/JCOk0Q5soP/A3yPi2XrthNFYkcGWaG+BcR
bbWCWEtcMjrslj01cl0hVi/qRtbnrwR+Z1TB8y1RROi/m0P8B7lnqsHsszHqwDCj
u4NfhxOLxZEuGQu0N21kkbqfu3MyvVHtZMGgESS7GuOl7pRGFQqFFCFeAuVuyvcz
INS1pSjm51MmP4YR4SKUMgFmZQuO7ygbvTjB7bsDc75vMqqbw5ZpZNATxEFHQS0H
y5XH3Y/cvzq0I6xyhYfvf4qiGvyhCNgxhzfxJmk79NG+36nXuuQ+6dpyvg5Ym6G5
sIFMhWI/O2OBTuUgYaPe9HkAgpykcUlQHBV4AhU64cQWJDHqeiZX3z3auaWKSPJd
3Jr8ZBwiT5cUv1lVUMDha8Qn1iSGM+RwhepTUoTiQE8Mg2NwT3D31EPdZJ6HGygN
QTSAVa8QVB7qFEmOhnpuKCuX70sVUDH3e11HBmBQyZJhNYMt8tvBPspRnAegbTMT
xag+gMxOFuXGmF4Aol+SLCmAaHAllikBFjEk/2FPGrpoiVAAB4d1gKiqwa8JePUn
NdH7yhugZzTEUk0e+Uj5hyhXug58HqGzetQAtE4uOrZG6XxbW5t+nXyy1i+8v5eM
bcZ7ScU4cLfcNoZgB8IXiP7OnCizaN5hcaeEebltxpgRvxH+FHlZz4aWIIpEl+zN
oLAWgcrd/r9xO+Fyw7lo
=HOEN
-----END PGP SIGNATURE-----
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

Here it is! Thank you!

Try placing 'mode=transport' in the OPTIONS column of vpn1's entry in
/etc/shorewall/zones.

Thanks,
- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[John Depp]

no changes :-(

Post by Tom Eastep
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Here it is! Thank you!

Try placing 'mode=transport' in the OPTIONS column of vpn1's entry in
/etc/shorewall/zones.
Thanks,
- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJYUcqgAAoJEJbms/JCOk0QeqsP/0JJaQ5R9E8QMYKB09qMxA7S
0g/bYjnqMdCSjSYSFFfrfndNWrXx0zt4Oo+g/5E22xo3lmT6HhEQssBLa3QPb+6m
dHEONTxRHjVJuZ1AoU6JqjxNueHtpk5EpzMY5jeymISvaBZAGllf3HyJgdH+rYrU
ydA6KqEiX6FtUiv91zp3B+a/5GPBqSDIsOIqrgXjl2AnZNTxf0vTXc5RBqn8blvq
eK9lopYobMN8CQy7vdEkL5uJvrD8lSFOEkQcbwmZByRdlNc+EE0GWT38x/es67E+
SNyX6rz9mMj6lU47a5eZeP5BLUK1UsMqCnzri1fDTp7+IshjEohUpkY7EgVJ94p/
wmD2S5HjivBhaTfDjTUdqDgpV10z8uYQl2DJ8VQ844E/UIGDv1sa9cvjLnZYdJuc
XvEvnCtRITfw1muvXPYCv8clJNAqyh0BTNz318tfepoH9Vm5h9ef9gecW8mKhMk7
YjMBujQnhxtasIj5AvtvttzQsrCKE8Jo1YecTVcEpjJPpjMHg5ZMD4KMmJnOpEj7
vkW0wMn++vUGmKd2xH1FO7mOKiugvSGmlOs9j7zrT4ty2X667s4VEVkXN7lVn+49
17g0esU0bsKt8XrxLolMTp0StZ3a05yi2ylyUROxa1x1g2VYsYQYC2ZRqj56YVGR
pkWjmKtGJl6wEuT104kt
=q7Sw
-----END PGP SIGNATURE-----
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

Post by John Depp
no changes :-(

Dump please. I'll be out for much of the day, but I'll look at it as
soon as I can.

- -Tom

- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[Tom Eastep]

Post by Tom Eastep

Post by John Depp
no changes :-(

Dump please. I'll be out for much of the day, but I'll look at it
as soon as I can.

But before you do that, try placing only

proto=esp

in the OPTIONS column of the vpn1 zone file entry.

- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[Tom Eastep]

Post by Tom Eastep
But before you do that, try placing only
proto=esp
in the OPTIONS column of the vpn1 zone file entry.

I have put together a test bed of my own and have been able to
reproduce the problem. Using standard Shorewall configuration methods,
I am unable to pass the IPIP packets.

I have a workaround, however. I created /etc/shorewall/start and added
the following command:

run_iptables -A eth0_in -s 10.2.10.2 -p 4 -j ACCEPT

where 10.2.10.2 is the remote IPSEC gateway. I then placed this in the
OPTIONS column of vpn1's entry in the zones file:

proto=esp,mode=transport

I will continue to work on this to come up with a cleaner solution.

Regards,
- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[Tom Eastep]

Post by Tom Eastep
I will continue to work on this to come up with a cleaner
solution.

I should add that I believe that this is a Netfilter issue. So the
solution will probably not be a change to Shorewall.

- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[John Depp]

Thank you very much for spending so much efforts to resolve my issue.

As I've mentioned the simplest way to avoid the problem is to turn off
ipcomp.
The only drawback is the way the ipcomp could be turned on or off in
strongswan - the single option
compress = <yes|no> does the thing, so many ppl (me included) could just
turn it on for good.

As for cleaner solution, I'd suggest removing the "policy match dir in pol
none" statement from eth0_in zone in net-fw rule - let all packets hit the
rule and then we could apply rules from shorewall/rules for them - but of
course I just don't see the whole picture and don't know why this statement
was inserted for.

I think i'll cease further efforts as I'm satisfied with no ipcomp at all.
Thank you anyways!

Post by Tom Eastep
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Tom Eastep
I will continue to work on this to come up with a cleaner
solution.

I should add that I believe that this is a Netfilter issue. So the
solution will probably not be a change to Shorewall.
- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJYVJj/AAoJEJbms/JCOk0QM/YP/2ViKrR7GL3BDG3k6xbWYP6B
wzJLjhKmunpLX7MlgtYDKkBnTYP7wdYanUTV0RZml+X09yCRQV2nK1EGS1Y2Qy/G
7I4LzKgTdCbOYSHhoyncAcUwd1iR2pnGCZiI9cfhUPJxAPGw8m2OK+j4bwHjENUG
HzeObWmZn+RtZ+Pvme2QwM7oHyC7oR1MFGp+dzkMtcSPo+fbqqg90tbcC2pZpHh+
H5jCD6IP+Cboomjf+3n3pTzOVeYW2lnLYNmj96zhcMV7B5kBz6mOf1Ax3IM0DWbM
TaluoOIprcnpal5+RLooDWD4GQTqNUZs+x2/ZjFCXzRL7cXTUIdK2ac83Svofb9h
/pyzfuXZIVRp9PAW9qzRlvBOFqeCt613PSC10mFutfL3gV+OLAjKpru8MIv9quDu
l+FLal8WJ8op9egS67iLVjj3N31lA9Te8xW3esJxKuPh9CvCFub8N8ecuPR4DB7j
wv9wNdEL9ypQ6Fp0p05zN+GQjB83WSTWCoRJmC4VvxIEfeyap18LB3wuTn2O0yBx
MiCIxwwCKCJI67ySL3fDUWv0buYnfFwg49m03FhJIJREyaoPabAsAJ0ZfFEZrGyr
fKV7javShb6y6SnrMB9GY26jiMTerfrXWg2hlCQyaBv/YWK4wF8VTg+gxx7SWc+7
zaD9Gg6+45w0YkS3R1w4
=zw/E
-----END PGP SIGNATURE-----
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

Post by John Depp
Thank you very much for spending so much efforts to resolve my
issue.
As I've mentioned the simplest way to avoid the problem is to turn
off ipcomp. The only drawback is the way the ipcomp could be
turned on or off in strongswan - the single option compress =
<yes|no> does the thing, so many ppl (me included) could just turn
it on for good.
As for cleaner solution, I'd suggest removing the "policy match
dir in pol none" statement from eth0_in zone in net-fw rule - let
all packets hit the rule and then we could apply rules from
shorewall/rules for them - but of course I just don't see the
whole picture and don't know why this statement was inserted for.

As I was documenting the problem, I realized that we both had a
Shorewall configuration issue. We both included only the peer's local
network in our /etc/shorewall/hosts definition of the vpn1 zone. When
ipcomp is used, we also need to have an entry with the peer gateway's
host address in it.

In my case:

#ZONE HOSTS OPTIONS
vpn1 eth0:172.21.1.0/24
vpn1 eth0:10.2.10.11

The OPTIONS column in vpn1's zone definition is empty.

You could also choose to simply include a single entry:

#ZONE HOSTS OPTIONS
vpn1 eth0:0.0.0.0/0

Then use entries in the rules to differentiate between different
remote networks.

I will make an update to the Shorewall IPSEC documentation to make
this clear.

- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________