Re: [Shorewall-users] Shorewall Disobeying rules?

[colony.three--- via Shorewall-users]

I see.  Chrony is getting blocked.

All this setup is temporary because soon it will be going through a WireGuard 
tunnel.




‐‐‐ Original Message ‐‐‐
On Wednesday, August 5, 2020 10:51 AM, Tom Eastep  wrote:

> On 8/5/20 10:30 AM, colony.three--- via Shorewall-users wrote:
>
> > HAZZAH, like magic the Master does it again!
> > This is regular Shorewall, compiling rules in its own machine, all in 
> > /etc/shorewall.
> > BUT, AUTOMAKE=Yes. As soon as I set it to No, everything started TWERKING!
> > Thank you again Tom. I never would have found this in a million years.
> > For others, beware: Automake=Yes is the default. Might should be No if you 
> > consider port-forwarding.
>
> The real problem is the time/date issue on that system. When the current
> time says 2018 and the firewall script was created in 2020, AUTOMAKE=Yes
> is going to prevent the script from getting re-generated for the next
> two years!!
>
> -Tom
>
> 
>
> Tom Eastep \ Q: What do you get when you cross a mobster
> Shoreline, \ with an international standard?
> Washington, USA \ A: Someone who makes you an offer you
> http://shorewall.org \ can't understand
> \
>
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users




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

Re: [Shorewall-users] Shorewall Disobeying rules?

[colony.three--- via Shorewall-users]

HAZZAH, like magic the Master does it again!

This is regular Shorewall, compiling rules in its own machine, all in 
/etc/shorewall.

BUT, AUTOMAKE=Yes.  As soon as I set it to No, everything started TWERKING!

Thank you again Tom.  I never would have found this in a million years.

For others, beware:  Automake=Yes is the default.  Might should be No if you 
consider port-forwarding.




‐‐‐ Original Message ‐‐‐
On Wednesday, August 5, 2020 10:18 AM, Tom Eastep  wrote:

> On 8/5/20 9:30 AM, colony.three--- via Shorewall-users wrote:
>
> > Thank you Tom, but actually there is a DNS ACCEPT rule.
> > I didn't make this clear enough but I am trying to dnat from net to local, 
> > for example incoming port 51554 to local 10.2.20.51:554 . Here are my rules:
> >
> > Cameras
> >
> > 
> >
> > ACCEPT net:10.2.1.4 $FW tcp 50554 -
> > DNAT net local:10.2.20.50:554 tcp 50554 -
> > ACCEPT net $FW tcp 51554 -
> > DNAT net local:10.2.20.51:554 tcp 51554 -
> > ACCEPT net:10.2.1.4 $FW udp 50554 -
> > DNAT net local:10.2.20.50:554 udp 50554 -
> > ACCEPT net:10.2.1.4 $FW udp 51554 -
> > DNAT net local:10.2.20.51:554 udp 51554 -
> > ACCEPT net:10.2.1.4 $FW tcp 50443 -
> > DNAT net local:10.2.20.50:443 tcp 50443 -
> > ACCEPT local $FW udp domain,ntp -
> > ACCEPT net $FW tcp 51443 -
> > DNAT net local:10.2.20.51:443 tcp 51443 -
> > ACCEPT net $FW tcp 5180 -
> > DNAT net local:10.2.20.51:80 tcp 5180 -
>
> Again, is this a Shorewall-lite system, or are you compiling on the box
> itself? If on the box itself and you are including these rules from a
> directory other than /etc/shorewall/, beware of your AUTOMAKE setting.
> If the directory is a subdirectory of /etc/shorewall, then you need
> AUTOMAKE=no, AUTOMAKE=recursive or AUTOMAKE=n where n >= 2. If the
>
> directory is not a sub-directory of /etc/shorewall, then you must set
> AUTOMAKE=no or you must add that directory to CONFIG_PATH.
>
> -Tom
>
> ---
>
> Tom Eastep \ Q: What do you get when you cross a mobster
> Shoreline, \ with an international standard?
> Washington, USA \ A: Someone who makes you an offer you
> http://shorewall.org \ can't understand
> \
>
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users




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

Re: [Shorewall-users] Shorewall Disobeying rules?

[colony.three--- via Shorewall-users]

Thank you Tom, but actually there is a DNS ACCEPT rule.

I didn't make this clear enough but I am trying to dnat from net to local, for 
example incoming port 51554 to local 10.2.20.51:554 .  Here are my rules:

# Cameras
ACCEPT  net:10.2.1.4$FW tcp 50554   -
DNATnet local:10.2.20.50:554tcp 50554   -
ACCEPT  net $FW tcp 51554   -
DNATnet local:10.2.20.51:554tcp 51554   -
ACCEPT  net:10.2.1.4$FW udp 50554   -
DNATnet local:10.2.20.50:554udp 50554   -
ACCEPT  net:10.2.1.4$FW udp 51554   -
DNATnet local:10.2.20.51:554udp 51554   -
ACCEPT  net:10.2.1.4$FW tcp 50443   -
DNATnet local:10.2.20.50:443tcp 50443   -
ACCEPT  local   $FW udp domain,ntp  -

ACCEPT  net $FW tcp 51443   -
DNATnet local:10.2.20.51:443tcp 51443   -

ACCEPT  net $FW tcp 5180-
DNATnet local:10.2.20.51:80 tcp 5180-


As a test I also tried incoming 5180 to local 10.2.20.51:80 but that doesn't 
work in a browser.  tcpdump shows traffic on both interfaces but a browser 
can't get a connexion. Here's what happens:

# tcpdump 'tcp port 5180' -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:13:30.083040 IP andromeda2.darkmtter.org.38466 > 10.2.1.106.5180: Flags [S], 
seq 4088927536, win 29200, options [mss 1460,nop,wscale 7], length 0
19:13:30.083860 IP 10.2.1.106.5180 > andromeda2.darkmtter.org.38466: Flags 
[S.], seq 2964644306, ack 4088927537, win 14600, options [mss 1460,nop,wscale 
4], length 0
19:13:30.084728 IP andromeda2.darkmtter.org.38466 > 10.2.1.106.5180: Flags [.], 
ack 1, win 229, length 0
19:13:30.085209 IP andromeda2.darkmtter.org.38466 > 10.2.1.106.5180: Flags 
[P.], seq 1:316, ack 1, win 229, length 315
19:13:30.085840 IP 10.2.1.106.5180 > andromeda2.darkmtter.org.38466: Flags [.], 
ack 316, win 980, length 0
19:13:30.087748 IP 10.2.1.106.5180 > andromeda2.darkmtter.org.38466: Flags 
[P.], seq 1:286, ack 316, win 980, length 285
19:13:30.088661 IP andromeda2.darkmtter.org.38466 > 10.2.1.106.5180: Flags [.], 
ack 286, win 237, length 0
19:13:30.089035 IP andromeda2.darkmtter.org.38466 > 10.2.1.106.5180: Flags 
[F.], seq 316, ack 286, win 237, length 0
19:13:30.123597 IP 10.2.1.106.5180 > andromeda2.darkmtter.org.38466: Flags [.], 
ack 317, win 980, length 0
19:13:30.942376 IP 10.2.1.106.5180 > andromeda2.darkmtter.org.38466: Flags 
[F.], seq 286, ack 317, win 980, length 0
19:13:30.944365 IP andromeda2.darkmtter.org.38466 > 10.2.1.106.5180: Flags [.], 
ack 287, win 237, length 0
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel

# tcpdump 'tcp port 80' -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
19:13:59.521650 IP andromeda2.darkmtter.org.38474 > 10.2.20.51.http: Flags [S], 
seq 3884695726, win 29200, options [mss 1460,nop,wscale 7], length 0
19:13:59.522504 IP 10.2.20.51.http > andromeda2.darkmtter.org.38474: Flags 
[S.], seq 3405756270, ack 3884695727, win 14600, options [mss 1460,nop,wscale 
4], length 0
19:13:59.523379 IP andromeda2.darkmtter.org.38474 > 10.2.20.51.http: Flags [.], 
ack 1, win 229, length 0
19:13:59.523848 IP andromeda2.darkmtter.org.38474 > 10.2.20.51.http: Flags 
[P.], seq 1:316, ack 1, win 229, length 315: HTTP: GET / HTTP/1.1
19:13:59.524422 IP 10.2.20.51.http > andromeda2.darkmtter.org.38474: Flags [.], 
ack 316, win 980, length 0
19:13:59.527942 IP 10.2.20.51.http > andromeda2.darkmtter.org.38474: Flags 
[P.], seq 1:286, ack 316, win 980, length 285: HTTP: HTTP/1.1 302 Moved 
Temporarily
19:13:59.529091 IP andromeda2.darkmtter.org.38474 > 10.2.20.51.http: Flags [.], 
ack 286, win 237, length 0
19:13:59.529487 IP andromeda2.darkmtter.org.38474 > 10.2.20.51.http: Flags 
[F.], seq 316, ack 286, win 237, length 0
19:13:59.565954 IP 10.2.20.51.http > andromeda2.darkmtter.org.38474: Flags [.], 
ack 317, win 980, length 0
19:13:59.651925 IP 10.2.20.51.http > andromeda2.darkmtter.org.38474: Flags 
[F.], seq 286, ack 317, win 980, length 0
19:13:59.652996 IP andromeda2.darkmtter.org.38474 > 10.2.20.51.http: Flags [.], 
ack 287, win 237, length 0
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel
#




‐‐‐ Original Message ‐‐‐
On Wednesday, August 5, 2020 9:09 AM, Tom Eastep  wrote:

> On 8/5/20 8:03 AM, colony.three--- via Shorewall-users wrote:
>
> > I have struggled for days to make this work but admit I am soundly defeate

Re: [Shorewall-users] Shorewall Disobeying rules?

[colony.three--- via Shorewall-users]

Hi Matt,

local (cameras) zone is 10.2.20.1 and net zone is 10.2.1.106.

If I do shorewall clear, dnat can't work.

I didn't try to access http/https during that snip.




‐‐‐ Original Message ‐‐‐
On Wednesday, August 5, 2020 9:01 AM, Matt Darfeuille  
wrote:

> On 8/5/2020 5:03 PM, colony.three--- via Shorewall-users wrote:
>
> > I have struggled for days to make this work but admit I am soundly defeated.
> > My goal is to dnat two cameras through an Odroid N2+. But I can't even get 
> > a basic ACCEPT to work on ports 80 or 443. I can't understand what is 
> > wrong. Dump is attached. Sure hope the boss is still around.
> > [Tue Jan 30 17:39:29 2018] net-fw DROP IN=eth0 OUT= 
> > MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
> > LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=8197 DF PROTO=TCP SPT=28086 DPT=51554 
> > WINDOW=29200 RES=0x00 SYN URGP=0
> > [Tue Jan 30 17:39:30 2018] local-fw REJECT IN=eth1 OUT= 
> > MAC=00:e0:4c:68:00:9e:dc:9f:db:1a:a0:1a:08:00 SRC=10.2.20.31 DST=10.2.20.1 
> > LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=10986 DF PROTO=UDP SPT=53625 DPT=53 
> > LEN=45
> > [Tue Jan 30 17:39:30 2018] local-fw REJECT IN=eth1 OUT= 
> > MAC=00:e0:4c:68:00:9e:dc:9f:db:1a:a0:1a:08:00 SRC=10.2.20.31 DST=10.2.20.1 
> > LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=10987 DF PROTO=UDP SPT=57493 DPT=53 
> > LEN=45
> > [Tue Jan 30 17:39:30 2018] local-fw REJECT IN=eth1 OUT= 
> > MAC=00:e0:4c:68:00:9e:dc:9f:db:1a:a0:1a:08:00 SRC=10.2.20.31 DST=10.2.20.1 
> > LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=10988 DF PROTO=UDP SPT=40352 DPT=53 
> > LEN=45
> > [Tue Jan 30 17:39:31 2018] net-fw DROP IN=eth0 OUT= 
> > MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
> > LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=10546 DF PROTO=TCP SPT=28190 DPT=51554 
> > WINDOW=29200 RES=0x00 SYN URGP=0
> > [Tue Jan 30 17:39:32 2018] net-fw DROP IN=eth0 OUT= 
> > MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
> > LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=10547 DF PROTO=TCP SPT=28190 DPT=51554 
> > WINDOW=29200 RES=0x00 SYN URGP=0
> > [Tue Jan 30 17:39:32 2018] local-fw REJECT IN=eth1 OUT= 
> > MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
> > LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44808 DF PROTO=UDP SPT=48844 DPT=53 
> > LEN=52
> > [Tue Jan 30 17:39:32 2018] local-fw REJECT IN=eth1 OUT= 
> > MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
> > LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44809 DF PROTO=UDP SPT=60419 DPT=53 
> > LEN=52
> > [Tue Jan 30 17:39:32 2018] local-fw REJECT IN=eth1 OUT= 
> > MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
> > LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44810 DF PROTO=UDP SPT=45791 DPT=53 
> > LEN=52
> > [Tue Jan 30 17:39:32 2018] local-fw REJECT IN=eth1 OUT= 
> > MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
> > LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44811 DF PROTO=UDP SPT=32787 DPT=53 
> > LEN=52
> > [Tue Jan 30 17:39:34 2018] net-fw DROP IN=eth0 OUT= 
> > MAC=01:00:5e:00:00:01:00:eb:d5:61:fb:60:08:00 SRC=0.0.0.0 DST=224.0.0.1 
> > LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
> > [Tue Jan 30 17:39:34 2018] net-fw DROP IN=eth0 OUT= 
> > MAC=01:00:5e:00:00:01:00:eb:d5:61:fb:60:08:00 SRC=0.0.0.0 DST=224.0.0.1 
> > LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
> > [Tue Jan 30 17:39:34 2018] net-fw DROP IN=eth0 OUT= 
> > MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
> > LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=10548 DF PROTO=TCP SPT=28190 DPT=51554 
> > WINDOW=29200 RES=0x00 SYN URGP=0
> > [Tue Jan 30 17:39:38 2018] net-fw DROP IN=eth0 OUT= 
> > MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
> > LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=10549 DF PROTO=TCP SPT=28190 DPT=51554 
> > WINDOW=29200 RES=0x00 SYN URGP=0
> > [Tue Jan 30 17:39:39 2018] local-fw REJECT IN=eth1 OUT= 
> > MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
> > LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44884 DF PROTO=UDP SPT=56118 DPT=53 
> > LEN=52
> > [Tue Jan 30 17:39:39 2018] local-fw REJECT IN=eth1 OUT= 
> > MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
> > LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44885 DF PROTO=UDP SPT=47795 DPT=53 
> > LEN=52
> > [Tue Jan 30 17:39:39 2018] local-fw REJECT IN=eth1 OUT= 
> > MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
> > LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44886 DF PROTO=UDP SPT=60806 DPT=53 
> > LEN=52
> &

[Shorewall-users] Shorewall Disobeying rules?

[colony.three--- via Shorewall-users]

I have struggled for days to make this work but admit I am soundly defeated.

My goal is to dnat two cameras through an Odroid N2+. But I can't even get a 
basic ACCEPT to work on ports 80 or 443. I can't understand what is wrong. Dump 
is attached. Sure hope the boss is still around.

[Tue Jan 30 17:39:29 2018] net-fw DROP IN=eth0 OUT= 
MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=8197 DF PROTO=TCP SPT=28086 DPT=51554 
WINDOW=29200 RES=0x00 SYN URGP=0
[Tue Jan 30 17:39:30 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:dc:9f:db:1a:a0:1a:08:00 SRC=10.2.20.31 DST=10.2.20.1 
LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=10986 DF PROTO=UDP SPT=53625 DPT=53 LEN=45
[Tue Jan 30 17:39:30 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:dc:9f:db:1a:a0:1a:08:00 SRC=10.2.20.31 DST=10.2.20.1 
LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=10987 DF PROTO=UDP SPT=57493 DPT=53 LEN=45
[Tue Jan 30 17:39:30 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:dc:9f:db:1a:a0:1a:08:00 SRC=10.2.20.31 DST=10.2.20.1 
LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=10988 DF PROTO=UDP SPT=40352 DPT=53 LEN=45
[Tue Jan 30 17:39:31 2018] net-fw DROP IN=eth0 OUT= 
MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=10546 DF PROTO=TCP SPT=28190 DPT=51554 
WINDOW=29200 RES=0x00 SYN URGP=0
[Tue Jan 30 17:39:32 2018] net-fw DROP IN=eth0 OUT= 
MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=10547 DF PROTO=TCP SPT=28190 DPT=51554 
WINDOW=29200 RES=0x00 SYN URGP=0
[Tue Jan 30 17:39:32 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44808 DF PROTO=UDP SPT=48844 DPT=53 LEN=52
[Tue Jan 30 17:39:32 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44809 DF PROTO=UDP SPT=60419 DPT=53 LEN=52
[Tue Jan 30 17:39:32 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44810 DF PROTO=UDP SPT=45791 DPT=53 LEN=52
[Tue Jan 30 17:39:32 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44811 DF PROTO=UDP SPT=32787 DPT=53 LEN=52
[Tue Jan 30 17:39:34 2018] net-fw DROP IN=eth0 OUT= 
MAC=01:00:5e:00:00:01:00:eb:d5:61:fb:60:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 
TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[Tue Jan 30 17:39:34 2018] net-fw DROP IN=eth0 OUT= 
MAC=01:00:5e:00:00:01:00:eb:d5:61:fb:60:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 
TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2
[Tue Jan 30 17:39:34 2018] net-fw DROP IN=eth0 OUT= 
MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=10548 DF PROTO=TCP SPT=28190 DPT=51554 
WINDOW=29200 RES=0x00 SYN URGP=0
[Tue Jan 30 17:39:38 2018] net-fw DROP IN=eth0 OUT= 
MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=10549 DF PROTO=TCP SPT=28190 DPT=51554 
WINDOW=29200 RES=0x00 SYN URGP=0
[Tue Jan 30 17:39:39 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44884 DF PROTO=UDP SPT=56118 DPT=53 LEN=52
[Tue Jan 30 17:39:39 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44885 DF PROTO=UDP SPT=47795 DPT=53 LEN=52
[Tue Jan 30 17:39:39 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44886 DF PROTO=UDP SPT=60806 DPT=53 LEN=52
[Tue Jan 30 17:39:39 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:00:1f:54:45:be:07:08:00 SRC=10.2.20.51 DST=10.2.20.1 
LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=44887 DF PROTO=UDP SPT=53807 DPT=53 LEN=52
[Tue Jan 30 17:39:45 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:dc:9f:db:1a:a0:1a:08:00 SRC=10.2.20.31 DST=10.2.20.1 
LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=25988 DF PROTO=UDP SPT=60181 DPT=53 LEN=45
[Tue Jan 30 17:39:45 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:dc:9f:db:1a:a0:1a:08:00 SRC=10.2.20.31 DST=10.2.20.1 
LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=25989 DF PROTO=UDP SPT=51672 DPT=53 LEN=45
[Tue Jan 30 17:39:45 2018] local-fw REJECT IN=eth1 OUT= 
MAC=00:e0:4c:68:00:9e:dc:9f:db:1a:a0:1a:08:00 SRC=10.2.20.31 DST=10.2.20.1 
LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=25990 DF PROTO=UDP SPT=54680 DPT=53 LEN=45
[Tue Jan 30 17:39:46 2018] net-fw DROP IN=eth0 OUT= 
MAC=00:1e:06:42:5b:57:fc:aa:14:71:ef:47:08:00 SRC=10.2.1.4 DST=10.2.1.106 
LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=10550 DF PROTO=TCP SPT=28190 DPT=51554 

Re: [Shorewall-users] ERROR: Invalid parameter (DROP), Multicast(DROP)

[colony.three--- via Shorewall-users]

Whups, reboot fixed it.  Pardon the noise.

--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] ERROR: Invalid parameter (DROP), Multicast(DROP)

[colony.three--- via Shorewall-users]

‐‐‐ Original Message ‐‐‐

On April 16, 2018 12:16 PM, <colony.th...@protonmail.ch> wrote:

> ​​
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On April 16, 2018 11:30 AM, Tom Eastep teas...@shorewall.net wrote:
> 
> > On 04/16/2018 11:03 AM, colony.three--- via Shorewall-users wrote:
> > 
> > > ‐‐‐ Original Message ‐‐‐
> > > 
> > > On April 16, 2018 10:56 AM, Tom Eastep teas...@shorewall.net wrote:
> > > 
> > > > On 04/16/2018 10:50 AM, colony.three--- via Shorewall-users wrote:
> > > > 
> > > > > ‐‐‐ Original Message ‐‐‐
> > > > > 
> > > > > On April 16, 2018 10:42 AM, Tom Eastep teas...@shorewall.net wrote:
> > > > > 
> > > > > > On 04/16/2018 10:24 AM, colony.three--- via Shorewall-users wrote:
> > > > > > 
> > > > > > > Anyone seen this?
> > > > > > > 
> > > > > > > Nov 29 01:42:29 Compiling MAC Filtration -- Phase 2...
> > > > > > > 
> > > > > > > Nov 29 01:42:29 Applying Policies...
> > > > > > > 
> > > > > > > Nov 29 01:42:29 Compiling /usr/share/shorewall/action.Broadcast 
> > > > > > > for
> > > > > > > 
> > > > > > > chain Broadcast...
> > > > > > > 
> > > > > > > Nov 29 01:42:29    ERROR: Invalid parameter (DROP),Multicast(DROP)
> > > > > > > 
> > > > > > > /usr/share/shorewall/action.Broadcast (line 1)
> > > > > > > 
> > > > > > > from  (line EOF)
> > > > > > > 
> > > > > > > shorewall version
> > > > > > > =
> > > > > > > 
> > > > > > > 5.0.15.6
> > > > > > 
> > > > > > Don't see why you would be getting that message on 5.0.15.6. What 
> > > > > > does
> > > > > > 
> > > > > > your /usr/share/shorewall/action.Broadcast look like?
> > > > 
> > > > What is your setting of DROP_DEFAULT in shorewall.conf?
> > > > 
> > > > -Tom
> > > 
> > > DROP_DEFAULT="Broadcast(DROP),Multicast(DROP)"
> > > 
> > > I didn't change it, but commenting it out does not help. Same with the 
> > > other settings which specify (DROP),Multicast(DROP).
> > > 
> > > I do have a restrictive sysctl, if that makes any difference. It's 
> > > working fine on all my other (CentOS7.4) machines. (attached)
> > 
> > Those setting are not valid on 5.0.15.6. The ability to list multiple
> > 
> > actions wasn't introduced until Shorewall 5.1.2.
> > 
> > -Tom
> 
> Oh, Ok. I'd grafted in my config from CentOS to the Pi.
> 
> Thanks Tom.


Except same error, now that I've replaced those stanzas with:

ACCEPT_DEFAULT="none"
DROP_DEFAULT=Drop
NFQUEUE_DEFAULT="none"
QUEUE_DEFAULT="none"
REJECT_DEFAULT=Reject

I'd copied the whole /etc/shorewall directory from CentOS to Raspbian.  I only 
find the bad stanzas in shorewall.conf but they're commented out now yet I get 
the same error.

--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] ERROR: Invalid parameter (DROP), Multicast(DROP)

[colony.three--- via Shorewall-users]

‐‐‐ Original Message ‐‐‐

On April 16, 2018 11:30 AM, Tom Eastep <teas...@shorewall.net> wrote:

> ​​
> 
> On 04/16/2018 11:03 AM, colony.three--- via Shorewall-users wrote:
> 
> > ‐‐‐ Original Message ‐‐‐
> > 
> > On April 16, 2018 10:56 AM, Tom Eastep teas...@shorewall.net wrote:
> > 
> > > On 04/16/2018 10:50 AM, colony.three--- via Shorewall-users wrote:
> > > 
> > > > ‐‐‐ Original Message ‐‐‐
> > > > 
> > > > On April 16, 2018 10:42 AM, Tom Eastep teas...@shorewall.net wrote:
> > > > 
> > > > > On 04/16/2018 10:24 AM, colony.three--- via Shorewall-users wrote:
> > > > > 
> > > > > > Anyone seen this?
> > > > > > 
> > > > > > Nov 29 01:42:29 Compiling MAC Filtration -- Phase 2...
> > > > > > 
> > > > > > Nov 29 01:42:29 Applying Policies...
> > > > > > 
> > > > > > Nov 29 01:42:29 Compiling /usr/share/shorewall/action.Broadcast for
> > > > > > 
> > > > > > chain Broadcast...
> > > > > > 
> > > > > > Nov 29 01:42:29    ERROR: Invalid parameter (DROP),Multicast(DROP)
> > > > > > 
> > > > > > /usr/share/shorewall/action.Broadcast (line 1)
> > > > > > 
> > > > > > from  (line EOF)
> > > > > > 
> > > > > > shorewall version
> > > > > > =
> > > > > > 
> > > > > > 5.0.15.6
> > > > > 
> > > > > Don't see why you would be getting that message on 5.0.15.6. What does
> > > > > 
> > > > > your /usr/share/shorewall/action.Broadcast look like?
> > > 
> > > What is your setting of DROP_DEFAULT in shorewall.conf?
> > > 
> > > -Tom
> > 
> > DROP_DEFAULT="Broadcast(DROP),Multicast(DROP)"
> > 
> > I didn't change it, but commenting it out does not help. Same with the 
> > other settings which specify (DROP),Multicast(DROP).
> > 
> > I do have a restrictive sysctl, if that makes any difference. It's working 
> > fine on all my other (CentOS7.4) machines. (attached)
> 
> Those setting are not valid on 5.0.15.6. The ability to list multiple
> 
> actions wasn't introduced until Shorewall 5.1.2.
> 
> -Tom
> 


Oh, Ok.  I'd grafted in my config from CentOS to the Pi.

Thanks Tom.

--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] ERROR: Invalid parameter (DROP), Multicast(DROP)

[colony.three--- via Shorewall-users]

‐‐‐ Original Message ‐‐‐

On April 16, 2018 10:56 AM, Tom Eastep <teas...@shorewall.net> wrote:

> ​​
> 
> On 04/16/2018 10:50 AM, colony.three--- via Shorewall-users wrote:
> 
> > ‐‐‐ Original Message ‐‐‐
> > 
> > On April 16, 2018 10:42 AM, Tom Eastep teas...@shorewall.net wrote:
> > 
> > > On 04/16/2018 10:24 AM, colony.three--- via Shorewall-users wrote:
> > > 
> > > > Anyone seen this?
> > > > 
> > > > Nov 29 01:42:29 Compiling MAC Filtration -- Phase 2...
> > > > 
> > > > Nov 29 01:42:29 Applying Policies...
> > > > 
> > > > Nov 29 01:42:29 Compiling /usr/share/shorewall/action.Broadcast for
> > > > 
> > > > chain Broadcast...
> > > > 
> > > > Nov 29 01:42:29    ERROR: Invalid parameter (DROP),Multicast(DROP)
> > > > 
> > > > /usr/share/shorewall/action.Broadcast (line 1)
> > > > 
> > > > from  (line EOF)
> > > > 
> > > > shorewall version
> > > > =
> > > > 
> > > > 5.0.15.6
> > > 
> > > Don't see why you would be getting that message on 5.0.15.6. What does
> > > 
> > > your /usr/share/shorewall/action.Broadcast look like?
> 
> What is your setting of DROP_DEFAULT in shorewall.conf?
> 
> -Tom
> 


DROP_DEFAULT="Broadcast(DROP),Multicast(DROP)"

I didn't change it, but commenting it out does not help.  Same with the other 
settings which specify (DROP),Multicast(DROP).

I do have a restrictive sysctl, if that makes any difference.  It's working 
fine on all my other (CentOS7.4) machines. (attached)



#--
# Security

## Kernel config START ##

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

# Kernel EXEC shield - for RedHat, CentOS, ...
#kernel.exec-shield = 1

# Make the addresses of mmap base, stack, heap and VDSO page randomized
kernel.randomize_va_space = 2

# Reboot system when kernel panic occur, oops will wait 30 seconds until call 
panic()
kernel.panic = 30
kernel.panic_on_oops = 30

# Disable magic-sysrq key
kernel.sysrq = 0

# No core dumps for SUID
fs.suid_dumpable = 0

# Set maximum amount of memory allocated to shm to 256MB
kernel.shmmax = 268435456

# Hide exposed kernel pointers regardless of privileges (2.6.38)
kernel.kptr_restrict = 2

# NULL pointer dereference, lowest virtual address which process can use for 
mapping
vm.mmap_min_addr = 4096

# Maximum number of file handles that the Linux kernel will allocate
fs.file-max = 65000

# Allow more PIDs
kernel.pid_max = 65536

## Kernel config END ##

## IPv4 networking START ##

# Increase the maximum amount of option memory buffers
net.core.optmem_max = 57344

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Disable Proxy ARP
net.ipv4.proxy_arp = 0

# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 15

# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time = 1800

# Enable tcp_window_scaling
net.ipv4.tcp_window_scaling = 1

# Turn off the tcp_sack
net.ipv4.tcp_sack = 0

# Turn off the tcp_timestamps
net.ipv4.tcp_timestamps = 0

# Enable ignoring broadcasts request
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Enable bad error message protection
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Prevent SYN attack
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 2

# Enable IP spoofing protection, turn on source route verification
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Log packets with impossible addresses to kernel
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.default.log_martians = 0

# Disable IP source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.forwarding=0
net.ipv4.conf.all.mc_forwarding=0
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.all.secure_redirects=0

# Buffer size autotuning - buffer size (and tcp window size) is dynamically 
updated for each connection.
# This option is not present in kernels older then 2.4.27 or 2.6.7 - update 
your kernel
# In that case tuning options net.ipv4.tcp_wmem and net.ipv4.tcp_rmem isnt 
recommended
net.ipv4.tcp_moderate_rcvbuf = 1

# Increase the tcp-time-wait buckets pool size
net.ipv4.tcp_max_tw_buckets = 144

# Increase allowed local port range
net.ipv4.ip_local_port_range = 1024 64000

# Increase the maximum memory used to reassemble IP fragments
net.ipv4.ipfrag_high_thresh = 512000
net.ipv4.ipfrag_low_thresh = 446464

Re: [Shorewall-users] ERROR: Invalid parameter (DROP), Multicast(DROP)

[colony.three--- via Shorewall-users]

‐‐‐ Original Message ‐‐‐

On April 16, 2018 10:42 AM, Tom Eastep <teas...@shorewall.net> wrote:

> ​​
> 
> On 04/16/2018 10:24 AM, colony.three--- via Shorewall-users wrote:
> 
> > Anyone seen this?
> > 
> > Nov 29 01:42:29 Compiling MAC Filtration -- Phase 2...
> > 
> > Nov 29 01:42:29 Applying Policies...
> > 
> > Nov 29 01:42:29 Compiling /usr/share/shorewall/action.Broadcast for
> > 
> > chain Broadcast...
> > 
> > Nov 29 01:42:29    ERROR: Invalid parameter (DROP),Multicast(DROP)
> > 
> > /usr/share/shorewall/action.Broadcast (line 1)
> > 
> >   from  (line EOF)
> > 
> > shorewall version
> > =
> > 
> > 5.0.15.6
> 
> Don't see why you would be getting that message on 5.0.15.6. What does
> 
> your /usr/share/shorewall/action.Broadcast look like?
> 
> -Tom

Hi Tom,

I should have mentioned that this is on the most current Raspbian, and an 
install of Shorewall I did yesterday.


DEFAULTS DROP,-

?if __ADDRTYPE
@1  -   -   -   ;; -m addrtype --dst-type BROADCAST
@1  -   -   -   ;; -m addrtype --dst-type MULTICAST
@1  -   -   -   ;; -m addrtype --dst-type ANYCAST
?else
?begin perl;

use Shorewall::IPAddrs;
use Shorewall::Config;
use Shorewall::Chains;

my ( $action ) = get_action_params( 1 );
my $chainref   = get_action_chain;
my ( $level, $tag )= get_action_logging;

add_commands $chainref, 'for address in $ALL_BCASTS; do';
incr_cmd_level $chainref;
log_rule_limit $level, $chainref, 'Broadcast' , $action, '', $tag, 'add', ' -d 
$address ' if $level$
add_jump $chainref, $action, 0, "-d \$address ";
decr_cmd_level $chainref;
add_commands $chainref, 'done';

log_rule_limit $level, $chainref, 'Broadcast' , $action, '', $tag, 'add', ' -d 
224.0.0.0/4 ' if $le$
add_jump $chainref, $action, 0, '-d 224.0.0.0/4 ';

1;

?end perl;
?endif




--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] ERROR: Invalid parameter (DROP),Multicast(DROP)

[colony.three--- via Shorewall-users]

Anyone seen this?
Nov 29 01:42:29 Compiling MAC Filtration -- Phase 2...
Nov 29 01:42:29 Applying Policies...
Nov 29 01:42:29 Compiling /usr/share/shorewall/action.Broadcast for chain 
Broadcast...
Nov 29 01:42:29ERROR: Invalid parameter (DROP),Multicast(DROP) 
/usr/share/shorewall/action.Broadcast (line 1)
  from  (line EOF)

# shorewall version
5.0.15.6--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Fw: IPV6 Tunnel Ping Fail

[colony.three--- via Shorewall-users]

‐‐‐ Original Message ‐‐‐

On April 6, 2018 2:32 PM, Tom Eastep <teas...@shorewall.net> wrote:

> ​​
> 
> On 04/06/2018 01:22 PM, colony.three--- via Shorewall-users wrote:
> 
> > ‐‐‐ Original Message ‐‐‐
> > 
> > On April 6, 2018 11:58 AM, colony.th...@protonmail.ch wrote:
> > 
> > > ‐‐‐ Original Message ‐‐‐
> > > 
> > > On April 6, 2018 11:44 AM, Tom Eastep teas...@shorewall.net wrote:
> > > 
> > > > > After shorewall6 clear, ping6 just hangs.
> > > > > 
> > > > > ping6 google.com
> > > > > 
> > > > > 
> > > > > PING google.com(sea15s01-in-x0e.1e100.net (2607:f8b0:400a:806::200e)) 
> > > > > 56 data bytes
> > > > > 
> > > > > ^C
> > > > > 
> > > > > --- google.com ping statistics ---
> > > > > 
> > > > > 20 packets transmitted, 0 received, 100% packet loss, time 19000ms
> > > > 
> > > > You routing is all screwed up. You are trying to use the same /64 on
> > > > 
> > > > three different networks. When you get a tunnel from HE, you get two /64
> > > > 
> > > > networks: one on the sit device, and one to use in your local 
> > > > network(s).
> > > > 
> > > > You can subdivide the second /64 between multiple networks, but then the
> > > > 
> > > > prefix length for those networks must be > 64 and you cannot use
> > > > 
> > > > stateless autoconfiguration.
> > > > 
> > > > -Tom
> > > > 
> > > > Tom Eastep \ Q: What do you get when you cross a mobster with
> > > > 
> > > > Shoreline, \ an international standard?
> > > > 
> > > > Washington, USA \ A: Someone who makes you an offer you can't
> > > > 
> > > > http://shorewall.org \ understand
> > > 
> > > Understand, but I do have 2001:470:a:c3::2 set on the tunnel interface, 
> > > and for the LAN I've set 2001:470:b:c3::/64 like they say.
> > > 
> > > ip -6 route
> > > ===
> > > 
> > > unreachable ::/96 dev lo metric 1024 error -113
> > > 
> > > unreachable :::0.0.0.0/96 dev lo metric 1024 error -113
> > > 
> > > 2001:470:a:c3::/64 dev he-ipv6 proto kernel metric 256
> > > 
> > > 2001:470:b:c3::/64 dev eth1 proto kernel metric 256
> > > 
> > > 2001:470:b:c3::/64 dev eth2 proto kernel metric 256
> > > 
> > > unreachable 2002:a00::/24 dev lo metric 1024 error -113
> > > 
> > > unreachable 2002:7f00::/24 dev lo metric 1024 error -113
> > > 
> > > unreachable 2002:a9fe::/32 dev lo metric 1024 error -113
> > > 
> > > unreachable 2002:ac10::/28 dev lo metric 1024 error -113
> > > 
> > > unreachable 2002:c0a8::/32 dev lo metric 1024 error -113
> > > 
> > > unreachable 2002:e000::/19 dev lo metric 1024 error -113
> > > 
> > > unreachable 3ffe:::/32 dev lo metric 1024 error -113
> > > 
> > > fe80::/64 dev eth1 proto kernel metric 256
> > > 
> > > fe80::/64 dev eth2 proto kernel metric 256
> > > 
> > > fe80::/64 dev eth0 proto kernel metric 256
> > > 
> > > fe80::/64 dev he-ipv6 proto kernel metric 256
> > > 
> > > default dev he-ipv6 metric 1024
> > > 
> > > True I don't have a gateway set on eth1, but that -is- the LAN gateway.
> > > 
> > > To set up the tunnel I'm using the systemd service copied almost 
> > > word-for-word from the Arch doc:
> > > 
> > > [Unit]
> > > 
> > > Description=he.net IPv6 tunnel
> > > 
> > > After=network.target
> > > 
> > > [Service]
> > > 
> > > Type=oneshot
> > > 
> > > RemainAfterExit=yes
> > > 
> > > ExecStart=/usr/sbin/ip tunnel add he-ipv6 mode sit remote 216.218.226.238 
> > > local 50.47.100.167 ttl 255
> > > 
> > > ExecStart=/usr/sbin/ip link set he-ipv6 up mtu 1480
> > > 
> > > ExecStart=/usr/sbin/ip addr add 2001:470:a:c3::2/64 dev he-ipv6
> > > 
> > > ExecStart=/usr/sbin/ip -6 route add ::/0 dev he-ipv6
> > > 
> > > ExecStop=/usr/sbin/ip -6 route del ::/0 dev he-ipv6
> > > 
> > > ExecStop=/usr/sbin/ip link set he-ipv6 down
> > > 
> > > ExecSt

Re: [Shorewall-users] Fw: IPV6 Tunnel Ping Fail

[colony.three--- via Shorewall-users]

‐‐‐ Original Message ‐‐‐

On April 6, 2018 11:58 AM,  wrote:

> ​​
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On April 6, 2018 11:44 AM, Tom Eastep teas...@shorewall.net wrote:
> 
> > > After shorewall6 clear, ping6 just hangs.
> > > 
> > > ping6 google.com
> > > 
> > > 
> > > PING google.com(sea15s01-in-x0e.1e100.net (2607:f8b0:400a:806::200e)) 56 
> > > data bytes
> > > 
> > > ^C
> > > 
> > > --- google.com ping statistics ---
> > > 
> > > 20 packets transmitted, 0 received, 100% packet loss, time 19000ms
> > 
> > You routing is all screwed up. You are trying to use the same /64 on
> > 
> > three different networks. When you get a tunnel from HE, you get two /64
> > 
> > networks: one on the sit device, and one to use in your local network(s).
> > 
> > You can subdivide the second /64 between multiple networks, but then the
> > 
> > prefix length for those networks must be > 64 and you cannot use
> > 
> > stateless autoconfiguration.
> > 
> > -Tom
> > 
> > Tom Eastep \ Q: What do you get when you cross a mobster with
> > 
> > Shoreline, \ an international standard?
> > 
> > Washington, USA \ A: Someone who makes you an offer you can't
> > 
> > http://shorewall.org \ understand
> 
> Understand, but I do have 2001:470:a:c3::2 set on the tunnel interface, and 
> for the LAN I've set 2001:470:b:c3::/64 like they say.
> 
> ip -6 route
> ===
> 
> unreachable ::/96 dev lo metric 1024 error -113
> 
> unreachable :::0.0.0.0/96 dev lo metric 1024 error -113
> 
> 2001:470:a:c3::/64 dev he-ipv6 proto kernel metric 256
> 
> 2001:470:b:c3::/64 dev eth1 proto kernel metric 256
> 
> 2001:470:b:c3::/64 dev eth2 proto kernel metric 256
> 
> unreachable 2002:a00::/24 dev lo metric 1024 error -113
> 
> unreachable 2002:7f00::/24 dev lo metric 1024 error -113
> 
> unreachable 2002:a9fe::/32 dev lo metric 1024 error -113
> 
> unreachable 2002:ac10::/28 dev lo metric 1024 error -113
> 
> unreachable 2002:c0a8::/32 dev lo metric 1024 error -113
> 
> unreachable 2002:e000::/19 dev lo metric 1024 error -113
> 
> unreachable 3ffe:::/32 dev lo metric 1024 error -113
> 
> fe80::/64 dev eth1 proto kernel metric 256
> 
> fe80::/64 dev eth2 proto kernel metric 256
> 
> fe80::/64 dev eth0 proto kernel metric 256
> 
> fe80::/64 dev he-ipv6 proto kernel metric 256
> 
> default dev he-ipv6 metric 1024
> 
> True I don't have a gateway set on eth1, but that -is- the LAN gateway.
> 
> To set up the tunnel I'm using the systemd service copied almost 
> word-for-word from the Arch doc:
> 
> [Unit]
> 
> Description=he.net IPv6 tunnel
> 
> After=network.target
> 
> [Service]
> 
> Type=oneshot
> 
> RemainAfterExit=yes
> 
> ExecStart=/usr/sbin/ip tunnel add he-ipv6 mode sit remote 216.218.226.238 
> local 50.47.100.167 ttl 255
> 
> ExecStart=/usr/sbin/ip link set he-ipv6 up mtu 1480
> 
> ExecStart=/usr/sbin/ip addr add 2001:470:a:c3::2/64 dev he-ipv6
> 
> ExecStart=/usr/sbin/ip -6 route add ::/0 dev he-ipv6
> 
> ExecStop=/usr/sbin/ip -6 route del ::/0 dev he-ipv6
> 
> ExecStop=/usr/sbin/ip link set he-ipv6 down
> 
> ExecStop=/usr/sbin/ip tunnel del he-ipv6
> 
> [Install]
> 
> WantedBy=multi-user.target


I must be being dense here.  Can someone please explain what Ton is telling me 
here?

--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPV6 Tunnel Ping Fail

[colony.three--- via Shorewall-users]

‐‐‐ Original Message ‐‐‐
On April 6, 2018 11:18 AM, colony.three--- via Shorewall-users 
<shorewall-users@lists.sourceforge.net> wrote:

> # ip address
> 7: he-ipv6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state 
> UNKNOWN qlen 1
> link/sit 50.47.100.167 peer 216.218.226.238
> inet6 2001:470:a:c3::2/64 scope global
>valid_lft forever preferred_lft forever
> inet6 fe80::322f:64a7/64 scope link
>valid_lft forever preferred_lft forever
> # ip -6 neighbor
>
> # ping6 google.com
> PING google.com(dfw25s08-in-x0e.1e100.net (2607:f8b0:4000:801::200e)) 56 data 
> bytes
> From Quantumn-1-pt.tunnel.tserv14.sea1.ipv6.he.net (2001:470:a:c3::2) 
> icmp_seq=1 Destination unreachable: Address unreachable
> ping: sendmsg: Operation not permitted
> From Quantumn-1-pt.tunnel.tserv14.sea1.ipv6.he.net (2001:470:a:c3::2) 
> icmp_seq=2 Destination unreachable: Address unreachable
> ping: sendmsg: Operation not permitted
> From Quantumn-1-pt.tunnel.tserv14.sea1.ipv6.he.net (2001:470:a:c3::2) 
> icmp_seq=3 Destination unreachable: Address unreachable
> ping: sendmsg: Operation not permitted
>
> Shorewall dump sent to Tom.

I know that incoming ping is required for a Hurricane tunnel, and I've allowed 
this:
Ping(ACCEPT)   net:66.220.2.74  $FW

(I don't want anyone else to ping) (CentOS7.4)

But I don't know whether there needs to be an IPV6 ping incoming, and there are 
no Shorewall6 messages in dmesg.

I can't find any evidence of how to allow protocol 41.

Hopefully LAN passage through this router VM is covered with:
net.ipv6.ip_forward = 1

G**gle is baffled.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] IPV6 Tunnel Ping Fail

[colony.three--- via Shorewall-users]

# ip address
7: he-ipv6@NONE:  mtu 1480 qdisc noqueue state 
UNKNOWN qlen 1
link/sit 50.47.100.167 peer 216.218.226.238
inet6 2001:470:a:c3::2/64 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::322f:64a7/64 scope link
   valid_lft forever preferred_lft forever
# ip -6 neighbor

# ping6 google.com
PING google.com(dfw25s08-in-x0e.1e100.net (2607:f8b0:4000:801::200e)) 56 data 
bytes
From Quantumn-1-pt.tunnel.tserv14.sea1.ipv6.he.net (2001:470:a:c3::2) 
icmp_seq=1 Destination unreachable: Address unreachable
ping: sendmsg: Operation not permitted
From Quantumn-1-pt.tunnel.tserv14.sea1.ipv6.he.net (2001:470:a:c3::2) 
icmp_seq=2 Destination unreachable: Address unreachable
ping: sendmsg: Operation not permitted
From Quantumn-1-pt.tunnel.tserv14.sea1.ipv6.he.net (2001:470:a:c3::2) 
icmp_seq=3 Destination unreachable: Address unreachable
ping: sendmsg: Operation not permitted

Shorewall dump sent to Tom.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec & IPV6

[colony.three--- via Shorewall-users]

‐‐‐ Original Message ‐‐‐

On April 3, 2018 5:37 PM, Tom Eastep <teas...@shorewall.net> wrote:

> ​​
> 
> On 04/03/2018 05:29 PM, colony.three--- via Shorewall-users wrote:
> 
> > I'm trying to convert to IPV6 but there's a little problem with the
> > 
> > hosts file on the IPSec gateway.
> > 
> > shorewall6 doesn't like any combination of IP ::0.  As in:
> > 
> > vpn eth0:::0
> > 
> > I typed out all the zeroes, used all colons, but I could not decrypt
> > 
> > what it wants.
> 
> As clearly described at
> 
> http://www.shorewall.org/configuration_file_basics.htm#idm429, IPv6
> 
> addresses must be enclosed in "[...]" in most contexts. This is a
> 
> ubiquitous *nix convention.
> 
> -Tom

Well search was not my friend in this case.

And, having run Linux exclusively for 22 years, the brackets are new to me.

Thanks.

--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] IPSec & IPV6

[colony.three--- via Shorewall-users]

I'm trying to convert to IPV6 but there's a little problem with the hosts file 
on the IPSec gateway.

shorewall6 doesn't like any combination of IP ::0.  As in:
vpn eth0:::0

I typed out all the zeroes, used all colons, but I could not decrypt what it 
wants.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] VPN Ping Rejected

[colony.three--- via Shorewall-users]

On March 29, 2018 5:02 PM, Tom Eastep  wrote:
> > 
> > ... I believe this is right when unknown IPs can come in through VPN?
> 
> You should be assigning the remote IP address via the sourceip
> 
> (=right or left) setting in ipsec.conf.

I can't because the remote initiator could be any one of several devices, which 
all have dynamic IPs.  I'm setting up so that there is no distinction between 
remote and LAN members, which means I need to move from static IPs to DHCP, for 
VPN, which I'm doing anyway for the LAN in a transition to IPV6. (for the sake 
of all that's holy).

Also I can't because I'm using the new swanctl methodology which dispenses with 
ipsec.conf, ipsec.secrets, etc.  There are about a thousand things that can go 
wrong and docs are chaotic, but I just about have it sussed out.

 
> > But nm I seem to have fixed it. In zones I did have mode=transport when I'm 
> > now using tunnel. I can ping now.
> 
> That would explain the failure you were seeing.

Good to know, thanks



--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] VPN Ping Rejected

[colony.three--- via Shorewall-users]

​

‐‐‐ Original Message ‐‐‐

On March 29, 2018 4:08 PM, Tom Eastep <teas...@shorewall.net> wrote:

> ​​
> 
> On 03/29/2018 04:06 PM, colony.three--- via Shorewall-users wrote:
> 
> > On March 29, 2018 1:17 PM, Tom Eastep teas...@shorewall.net wrote:
> > 
> > > On 03/29/2018 11:59 AM, colony.three--- via Shorewall-users wrote:
> > > 
> > > > I don't understand why my ping through IPSec VPN is being rejected?
> > > > 
> > > > When I 'shorewall clear', it pings.
> > > > 
> > > > [138450.833070] Shorewall:INPUT:REJECT:IN=eth0 OUT=
> > > > 
> > > > MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114
> > > > 
> > > > DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44281 DF PROTO=ICMP
> > > > 
> > > > TYPE=8 CODE=0 ID=10 SEQ=48
> > > > 
> > > > [138450.833140] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16
> > > > 
> > > > DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=32617 PROTO=ICMP
> > > > 
> > > > TYPE=3 CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00
> > > > 
> > > > PREC=0x00 TTL=64 ID=44281 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=48 ]
> > > > 
> > > > [138451.840340] Shorewall:INPUT:REJECT:IN=eth0 OUT=
> > > > 
> > > > MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114
> > > > 
> > > > DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44409 DF PROTO=ICMP
> > > > 
> > > > TYPE=8 CODE=0 ID=10 SEQ=49
> > > > 
> > > > [138451.840413] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16
> > > > 
> > > > DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=33142 PROTO=ICMP
> > > > 
> > > > TYPE=3 CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00
> > > > 
> > > > PREC=0x00 TTL=64 ID=44409 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=49 ]
> > > > 
> > > > [138453.080442] Shorewall:INPUT:REJECT:IN=eth0 OUT=
> > > > 
> > > > MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114
> > > > 
> > > > DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44493 DF PROTO=ICMP
> > > > 
> > > > TYPE=8 CODE=0 ID=10 SEQ=50
> > > > 
> > > > [138453.080539] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16
> > > > 
> > > > DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=33370 PROTO=ICMP
> > > > 
> > > > TYPE=3 CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00
> > > > 
> > > > PREC=0x00 TTL=64 ID=44493 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=50 ]
> > > > 
> > > > [138453.821013] Shorewall:INPUT:REJECT:IN=eth0 OUT=
> > > > 
> > > > MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114
> > > > 
> > > > DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44587 DF PROTO=ICMP
> > > > 
> > > > TYPE=8 CODE=0 ID=10 SEQ=51
> > > > 
> > > > [138453.821035] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16
> > > > 
> > > > DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=33962 PROTO=ICMP
> > > > 
> > > > TYPE=3 CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00
> > > > 
> > > > PREC=0x00 TTL=64 ID=44587 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=51 ]
> > > > 
> > > > [138454.832916] Shorewall:INPUT:REJECT:IN=eth0 OUT=
> > > > 
> > > > MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114
> > > > 
> > > > DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44703 DF PROTO=ICMP
> > > > 
> > > > TYPE=8 CODE=0 ID=10 SEQ=52
> > > > 
> > > > [138454.832981] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16
> > > > 
> > > > DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=34910 PROTO=ICMP
> > > > 
> > > > TYPE=3 CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00
> > > > 
> > > > PREC=0x00 TTL=64 ID=44703 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=52 ]
> > > > 
> > > > Current Shorewall.
> > > > 
> > > > Ping(ACCEPT)    $FW net icmp    3,echo-request
> > > > 
> > > > Ping(ACCEPT)    $FW vpn icmp    3,echo-request
> > > > 
> > > > Ping(A

Re: [Shorewall-users] VPN Ping Rejected

[colony.three--- via Shorewall-users]

On March 29, 2018 1:17 PM, Tom Eastep <teas...@shorewall.net> wrote:

> ​​
> 
> On 03/29/2018 11:59 AM, colony.three--- via Shorewall-users wrote:
> 
> > I don't understand why my ping through IPSec VPN is being rejected? 
> > 
> > When I 'shorewall clear', it pings.
> > 
> > [138450.833070] Shorewall:INPUT:REJECT:IN=eth0 OUT=
> > 
> > MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114
> > 
> > DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44281 DF PROTO=ICMP
> > 
> > TYPE=8 CODE=0 ID=10 SEQ=48
> > 
> > [138450.833140] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16
> > 
> > DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=32617 PROTO=ICMP
> > 
> > TYPE=3 CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00
> > 
> > PREC=0x00 TTL=64 ID=44281 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=48 ]
> > 
> > [138451.840340] Shorewall:INPUT:REJECT:IN=eth0 OUT=
> > 
> > MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114
> > 
> > DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44409 DF PROTO=ICMP
> > 
> > TYPE=8 CODE=0 ID=10 SEQ=49
> > 
> > [138451.840413] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16
> > 
> > DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=33142 PROTO=ICMP
> > 
> > TYPE=3 CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00
> > 
> > PREC=0x00 TTL=64 ID=44409 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=49 ]
> > 
> > [138453.080442] Shorewall:INPUT:REJECT:IN=eth0 OUT=
> > 
> > MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114
> > 
> > DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44493 DF PROTO=ICMP
> > 
> > TYPE=8 CODE=0 ID=10 SEQ=50
> > 
> > [138453.080539] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16
> > 
> > DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=33370 PROTO=ICMP
> > 
> > TYPE=3 CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00
> > 
> > PREC=0x00 TTL=64 ID=44493 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=50 ]
> > 
> > [138453.821013] Shorewall:INPUT:REJECT:IN=eth0 OUT=
> > 
> > MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114
> > 
> > DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44587 DF PROTO=ICMP
> > 
> > TYPE=8 CODE=0 ID=10 SEQ=51
> > 
> > [138453.821035] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16
> > 
> > DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=33962 PROTO=ICMP
> > 
> > TYPE=3 CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00
> > 
> > PREC=0x00 TTL=64 ID=44587 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=51 ]
> > 
> > [138454.832916] Shorewall:INPUT:REJECT:IN=eth0 OUT=
> > 
> > MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114
> > 
> > DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44703 DF PROTO=ICMP
> > 
> > TYPE=8 CODE=0 ID=10 SEQ=52
> > 
> > [138454.832981] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16
> > 
> > DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=34910 PROTO=ICMP
> > 
> > TYPE=3 CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00
> > 
> > PREC=0x00 TTL=64 ID=44703 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=52 ]
> > 
> > Current Shorewall.
> > 
> > Ping(ACCEPT)    $FW net icmp    3,echo-request
> > 
> > Ping(ACCEPT)    $FW vpn icmp    3,echo-request
> > 
> > Ping(ACCEPT)   net:192.168.1.0/24 $FW    icmp    3,echo-request
> > 
> > Ping(ACCEPT)    vpn $FW icmp    3,echo-request
> 
> As always, when packets are rejected in the INPUT or OUTPUT chains, it
> 
> indicates that the SOURCE or DEST addresses respectively are not in any
> 
> defined zone. See Shorewall FAQ 17.
> 
> The above rules are overkill. You simply need:
> 
> Ping(ACCEPT) $FW net
> 
> Ping(ACCEPT) $FW vpn
> 
> Ping(ACCEPT) net:192.168.1.0/24 $FW
> 
> Ping(ACCEPT) vpn $FW
> 
> -Tom

I should have thought.  But here's my zones file:
fw  firewall
net ipv4
vpn ipsec 

And interfaces:
-   lo  ignore
net eth0routefilter,dhcp,tcpflags

And policy:
$FW all REJECT  info(uid)
net all DROPinfo(uid)
vpn all DROPinfo(uid)
#local  all REJECT  info(uid)
all all REJECT  info(uid)

Thanks, I'll make the corrections to my Ping macros.

--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] VPN Ping Rejected

[colony.three--- via Shorewall-users]

I don't understand why my ping through IPSec VPN is being rejected?  When I 
'shorewall clear', it pings.

[138450.833070] Shorewall:INPUT:REJECT:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114 
DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44281 DF PROTO=ICMP TYPE=8 
CODE=0 ID=10 SEQ=48
[138450.833140] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16 
DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=32617 PROTO=ICMP TYPE=3 
CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=44281 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=48 ]
[138451.840340] Shorewall:INPUT:REJECT:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114 
DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44409 DF PROTO=ICMP TYPE=8 
CODE=0 ID=10 SEQ=49
[138451.840413] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16 
DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=33142 PROTO=ICMP TYPE=3 
CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=44409 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=49 ]
[138453.080442] Shorewall:INPUT:REJECT:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114 
DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44493 DF PROTO=ICMP TYPE=8 
CODE=0 ID=10 SEQ=50
[138453.080539] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16 
DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=33370 PROTO=ICMP TYPE=3 
CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=44493 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=50 ]
[138453.821013] Shorewall:INPUT:REJECT:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114 
DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44587 DF PROTO=ICMP TYPE=8 
CODE=0 ID=10 SEQ=51
[138453.821035] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16 
DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=33962 PROTO=ICMP TYPE=3 
CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=44587 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=51 ]
[138454.832916] Shorewall:INPUT:REJECT:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=192.168.1.114 
DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44703 DF PROTO=ICMP TYPE=8 
CODE=0 ID=10 SEQ=52
[138454.832981] Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.16 
DST=192.168.1.114 LEN=112 TOS=0x00 PREC=0xC0 TTL=64 ID=34910 PROTO=ICMP TYPE=3 
CODE=1 [SRC=192.168.1.114 DST=192.168.1.16 LEN=84 TOS=0x00 PREC=0x00 TTL=64 
ID=44703 DF PROTO=ICMP TYPE=8 CODE=0 ID=10 SEQ=52 ]

Current Shorewall.

Ping(ACCEPT)$FW net icmp3,echo-request
Ping(ACCEPT)$FW vpn icmp3,echo-request
Ping(ACCEPT)   net:192.168.1.0/24 $FWicmp3,echo-request
Ping(ACCEPT)vpn $FW icmp3,echo-request--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Getting Blocked

[colony.three--- via Shorewall-users]

​​

‐‐‐ Original Message ‐‐‐

On March 23, 2018 9:43 AM, Tom Eastep <teas...@shorewall.net> wrote:

> ​​
> 
> On 03/22/2018 10:03 AM, colony.three--- via Shorewall-users wrote:
> 
> > No change in the symptom with 'shorewall clear' on the IPSEC gateway.
> > 
> > But I do notice that the response being emitted by the daemon which is not 
> > received by the phone (nor even seen in the IPSec gateway interface):
> > 
> > Thu, 2018-03-22 09:51 12[IKE] <3> sending keep alive to 172.56.42.76[49548]
> > 
> > Thu, 2018-03-22 09:51 12[MGR] <3> checkin IKE_SA (unnamed)[3]
> > 
> > Thu, 2018-03-22 09:51 12[MGR] <3> checkin of IKE_SA successful
> > 
> > Thu, 2018-03-22 09:51 04[NET] sending packet: from 192.168.111.16[4500] to 
> > 172.56.42.76[49548]
> > 
> > Thu, 2018-03-22 09:51 01[JOB] next event in 10s 3ms, waiting
> > 
> > ... has a -source- of 4500, not a destination of 4500. I'm not opening this 
> > in either the IPSec gateway nor the LAN gateway:
> > 
> > IPSec gateway rules:
> > 
> > ACCEPT $FW net udp 500,4500,ipsec,ipsec-nat -
> > 
> > LAN gateway snat
> > 
> > MASQUERADE 10.1.1.30/32,192.168.111.0/24 eth0
> > 
> > rules
> > 
> > ACCEPT local net udp domain -
> > 
> > DNAT net local:192.168.111.16 udp 500,ipsec-nat-t - 
> > 
> > It's UDP so unstateful, so maybe this is -a- problem? (Aside from the fact 
> > that the 4500 response doesn't seem to leave the daemon)
> 
> The conntrack entries on the gateways will allow the response packets to
> 
> be sent. Using tcpdump on the IPSEC gateway, do you see the response
> 
> packets being sent?
> 
> -Tom
> 
> 
> -
> 
> Tom Eastep \ Q: What do you get when you cross a mobster with
> 
> Shoreline, \ an international standard?
> 
> Washington, USA \ A: Someone who makes you an offer you can't
> 
> http://shorewall.org \ understand
> 
> ___
> 
> 
> -
> 
> 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
> 
> Shorewall-users@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/shorewall-users

Oh man.  I don't have any IPSec entries in conntrack.
?FORMAT 3
##
#ACTION SOURCE  DESTPROTO   DPORT   
SPORT   USERSWITCH

?if $AUTOHELPERS && __CT_TARGET

?if __AMANDA_HELPER
CT:helper:amanda:PO -   -   udp 10080
?endif

?if __FTP_HELPER
CT:helper:ftp:PO-   -   tcp 21
?endif

?if __H323_HELPER
CT:helper:RAS:PO-   -   udp 1719
CT:helper:Q.931:PO  -   -   tcp 1720
?endif

?if __IRC_HELPER
CT:helper:irc:PO-   -   tcp 6667
?endif

?if __NETBIOS_NS_HELPER
CT:helper:netbios-ns:PO -   -   udp 137
?endif

?if __PPTP_HELPER
CT:helper:pptp:PO   -   -   tcp 1723
?endif

?if __SANE_HELPER
CT:helper:sane:PO   -   -   tcp 6566
?endif

?if __SIP_HELPER
CT:helper:sip:PO-   -   udp 5060
?endif

?if __SNMP_HELPER
CT:helper:snmp:PO   -   -   udp 161
?endif

?if __TFTP_HELPER
CT:helper:tftp:PO   -   -   udp 69
?endif

?endif

--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Getting Blocked

[colony.three--- via Shorewall-users]

No change in the symptom with 'shorewall clear' on the IPSEC gateway.

But I do notice that the response being emitted by the daemon which is not 
received by the phone (nor even seen in the IPSec gateway interface):
Thu, 2018-03-22 09:51 12[IKE] <3> sending keep alive to 172.56.42.76[49548]
Thu, 2018-03-22 09:51 12[MGR] <3> checkin IKE_SA (unnamed)[3]
Thu, 2018-03-22 09:51 12[MGR] <3> checkin of IKE_SA successful
Thu, 2018-03-22 09:51 04[NET] sending packet: from 192.168.111.16[4500] to 
172.56.42.76[49548]
Thu, 2018-03-22 09:51 01[JOB] next event in 10s 3ms, waiting

... has a -source- of 4500, not a destination of 4500.  I'm not opening this in 
either the IPSec gateway nor the LAN gateway:

IPSec gateway rules:
ACCEPT  $FW net udp 500,4500,ipsec,ipsec-nat -

LAN gateway snat
MASQUERADE  10.1.1.30/32,192.168.111.0/24   eth0
rules
ACCEPT  local   net udp domain  -
DNATnet local:192.168.111.16 udp 500,ipsec-nat-t -  


It's UDP so unstateful, so maybe this is -a- problem?  (Aside from the fact 
that the 4500 response doesn't seem to leave the daemon)

​​

‐‐‐ Original Message ‐‐‐

On March 21, 2018 4:06 PM, Tom Eastep <teas...@shorewall.net> wrote:

> ​​
> 
> If you 'shorewall clear' on the IPSEC gateway, does that correct the
> 
> problem?
> 
> -Tom
> 
> On 03/21/2018 02:28 PM, colony.three--- via Shorewall-users wrote:
> 
> > The remote phone's Strongswan app is not getting a port 4500 response
> > 
> > back from the IPSec gateway.  It's trying and waiting for a response on
> > 
> > port 4500.
> > 
> > ‐‐‐ Original Message ‐‐‐
> > 
> > On March 21, 2018 9:35 AM, colony.th...@protonmail.ch wrote:
> > 
> > > I have an IPSec gateway, which is just an OpenStack instance in my
> > > 
> > > LAN.  Remote machines reach it with Strongswan through the LAN
> > > 
> > > gateway.  When I try to set up the VPN using a remote phone and the
> > > 
> > > Strongswan app it gets a good bit of the ways, but times out waiting
> > > 
> > > for a port 4500 response from the IPSec gateway.  The IPSec gateway
> > > 
> > > for its part claims that it'd sent the port 4500 response which never
> > > 
> > > gets there.
> > > 
> > > There are no Shorewall messages in dmesg regarding ports 500 or 4500,
> > > 
> > > in either the IPSec gateway or the LAN gateway.
> > > 
> > > IPSec gateway:
> > > 
> > > rules:
> > > 
> > > VPN
> > > ===
> > > 
> > > ACCEPT  net $FW udp 500,4500 -
> > > 
> > > ACCEPT  $FW net udp 500,4500 -
> > > 
> > > snat:
> > > 
> > > MASQUERADE  192.168.111.0/24    eth0
> > > 
> > > LAN gateway:
> > > 
> > > rules
> > > 
> > > VPN
> > > ===
> > > 
> > > DNAT    net local:192.168.111.16 udp
> > > 
> > > 500,ipsec-nat-t -  
> > > 
> > > snat
> > > 
> > > MASQUERADE  10.1.1.30/32,192.168.111.0/24   eth0
> > > 
> > > (10.1.1.30 is the DMZ)
> > > 
> > > The goal is to have all remote machines and all machines in the LAN
> > > 
> > > communicate by VPN transparently.  I'm back to basics with just an
> > > 
> > > IPSec gateway and one remote machine.  I suspect that when I get all
> > > 
> > > the LAN machines on trapped IPSec that the devices which do not
> > > 
> > > support IPSec (printers, Z-wave) will need to reach the rest of the
> > > 
> > > LAN through the IPSec gateway so am using SNAT there.
> > > 
> > > So for some reason it seems that port 4500 is getting blocked outgoing
> > > 
> > > from the IPSec gateway.  For some reason # tcpdump 'tcp port 500' and
> > > 
> > > 4500 yield -nothing- when aimed at the relevant interfaces on both
> > > 
> > > gateways. shorewall_dump.txt forwarded directly to Tom.
> > 
> > On the LAN gateway, I see lots of packets going in to the IPSec gateway
> > 
> > on (internal) eth1, but none going back out:
> > 
> > tcpdump -i eth1 'port 4500'
> > ===
> > 
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> > 
> > listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
> > 
> > 13:26:44.372723 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t:
>

Re: [Shorewall-users] IPSec Getting Blocked

[colony.three--- via Shorewall-users]

The remote phone's Strongswan app is not getting a port 4500 response back from 
the IPSec gateway.  It's trying and waiting for a response on port 4500.

‐‐‐ Original Message ‐‐‐
On March 21, 2018 9:35 AM,  wrote:

> I have an IPSec gateway, which is just an OpenStack instance in my LAN.  
> Remote machines reach it with Strongswan through the LAN gateway.  When I try 
> to set up the VPN using a remote phone and the Strongswan app it gets a good 
> bit of the ways, but times out waiting for a port 4500 response from the 
> IPSec gateway.  The IPSec gateway for its part claims that it'd sent the port 
> 4500 response which never gets there.
>
> There are no Shorewall messages in dmesg regarding ports 500 or 4500, in 
> either the IPSec gateway or the LAN gateway.
>
> IPSec gateway:
> rules:
> # VPN
> ACCEPT  net $FW udp 500,4500 -
> ACCEPT  $FW net udp 500,4500 -
>
> snat:
> MASQUERADE  192.168.111.0/24eth0
>
> LAN gateway:
> rules
>
> # VPN
> DNATnet local:192.168.111.16 udp 500,ipsec-nat-t -
>   
>
> snat
> MASQUERADE  10.1.1.30/32,192.168.111.0/24   eth0
>
> (10.1.1.30 is the DMZ)
>
> The goal is to have all remote machines and all machines in the LAN 
> communicate by VPN transparently.  I'm back to basics with just an IPSec 
> gateway and one remote machine.  I suspect that when I get all the LAN 
> machines on trapped IPSec that the devices which do not support IPSec 
> (printers, Z-wave) will need to reach the rest of the LAN through the IPSec 
> gateway so am using SNAT there.
>
> So for some reason it seems that port 4500 is getting blocked outgoing from 
> the IPSec gateway.  For some reason # tcpdump 'tcp port 500' and 4500 yield 
> -nothing- when aimed at the relevant interfaces on both gateways. 
> shorewall_dump.txt forwarded directly to Tom.

---
On the LAN gateway, I see lots of packets going in to the IPSec gateway on 
(internal) eth1, but none going back out:

# tcpdump -i eth1 'port 4500'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
13:26:44.372723 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:44.375540 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:44.377621 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:44.380078 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:44.383287 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:44.385543 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:44.398217 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:44.400500 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:46.422571 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:46.426444 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:46.430634 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:46.439986 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:46.445641 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:46.449896 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:46.452713 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:46.455215 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:49.198687 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:49.203642 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:49.208845 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:49.214348 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:49.218238 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:49.225086 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:49.231584 IP 172.56.42.131.39547 > 192.168.111.16.ipsec-nat-t: 
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
13:26:49.234940 IP 

[Shorewall-users] Generalized IPSec

[Colony.three via Shorewall-users]

We have LAN, made up of a number of KVM virtual machines, one of which is the 
router for the WAN and another is the IPSec gateway. (Libreswan)

I have DNAT working fine from the (internal) IPSec gateway through the router 
to my phone and back.  A while ago Tom gave me an iptables command to allow the 
phone access to the rest of the LAN.  But it doesn't work in the reverse, and 
it may not be the Shorewall way to do traffic in both directions, although I 
have no evidence of this.

So there exists the LAN, remote phones, remote laptops, and a remote mail 
server.  We'd like all to communicate democratically using Libreswan, each with 
their own auth credentials.  The Libreswan part is no problem, but I can't 
figure out how to direct traffic originating from the LAN to the relevant other 
locations using SNAT (through the IPSec gateway), and, in the reverse direction.

Ideally I'd like the VPN to have its own class C IPs with -static- (or known) 
addresses, so they are predictable, although I don't know how to do this.  Also 
I'd like all IPSec traffic to/from the LAN to go through the IPSec gateway, 
although I don't know how to do this with Shorewall.

Chances are good I can get any Libreswan questions answered by others, but it's 
the DNAT and SNAT issues that I can't sort out from the docs for this use-case.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

>> Libreswan does as well, although the devs (who are very helpful) assure
>> me it doesn't work.
>
> Bummer.

Indeed when putting in ipsec.conf, the config setup section (as called for in 
man ipsec.conf):
ikeport = 5500

... and restarting, it merrily disobeys and stays on 500.  And interfaces = 
eth0 doesn't work either, it listens on everything (including IPv6 which is 
turned off in the kernel).

I've asked devs on IRC, but for some reason they're usually gone Sundays...  
that's weird.  What's a "day off"?

No one seems to appreciate my motivations for wanting to change ports 
(including them and Ss devs) -- and I can't seem to explain the benefits of 
port knocking, nor pre-standard lattice encryption, either.  These are all 
high-grade security-related concerns, but I guess I have what I have.  All I 
can do is lobby.

I could probably change ports in Strongswan, but I am not going back there 
no-how for nothin'.

>
>
>> I'll try it anyway like the smartass I am.
>> Thanks for confirming that my port change kludge doesn't work.  It does
>> seem though that that last monitor is still encapsulated as the payload
>> contains the whole packet (736 bytes) rather than unwrapping the data (708).
>
> The IPv4 header is 20 bytes (with no options specified) and the UDP
> header is 8 bytes (source and destination port numbers, payload length
> and checksum). 20 + 8 + 708 = 736.

Sure.  But notice in the first monitor that the data payload is broken out as 
708 bytes, and then the whole packet is recognized as 736.  But in the last 
monitor we're looking only at the whole packet (as we were in the middle 
monitor), and the data payload isn't recognized, so I suspicion we're not 
deNATted yet.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

> I don't know about Libreswan, but Strongswan has options to change the
>
> IKE and NAT-T ports (charon.port and charon.port_nat_5 respectively).
>
> -Tom

Libreswan does as well, although the devs (who are very helpful) assure me it 
doesn't work.  I'll try it anyway like the smartass I am.

Thanks for confirming that my port change kludge doesn't work.  It does seem 
though that that last monitor is still encapsulated as the payload contains the 
whole packet (736 bytes) rather than unwrapping the data (708).

Once I get this sorted out, I'll be VPNning into zeta, a CentOS minimal 
installation in my LAN.  I'll probably use reverse SSH tunnels to pull in the 
SSH ports from other machines in the LAN to zeta localhost, so I don't need to 
directly reach outside of zeta.  Then I can x2go into each machine that has a 
GUI, from remote laptop and phone (assuming I can find an Android x2go app 
that's any good) .

Only problem then will be reaching The Internets through VPN and zeta.  Zeta 
can reach Internet now by normal means, but I may need SNAT of some sort to 
plumb the VPN there.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

> Have you tried comparing the packets arriving from the net with those being 
> sent to the IPSEC endpoint?
>
> -Tom

The following three monitors are recording the same attempt to connect.  First, 
on the LAN router, listening to the outside interface:

# tcpdump -vv -i eth0 'udp port 5500 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - 
((udp[12]&0xf0)>>2)) != 0)'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 
bytes
08:51:01.009320 IP (tos 0x0, ttl 55, id 4126, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > draco.darkmatter.org.5500: [udp sum ok] UDP, length 
708
08:51:02.889997 IP (tos 0x0, ttl 55, id 4127, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > draco.darkmatter.org.5500: [udp sum ok] UDP, length 
708
08:51:05.704119 IP (tos 0x0, ttl 55, id 4128, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > draco.darkmatter.org.5500: [udp sum ok] UDP, length 
708
08:51:09.663990 IP (tos 0x0, ttl 55, id 4129, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > draco.darkmatter.org.5500: [udp sum ok] UDP, length 
708
08:51:15.147943 IP (tos 0x0, ttl 55, id 4130, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > draco.darkmatter.org.5500: [udp sum ok] UDP, length 
708
^C
5 packets captured
9 packets received by filter
0 packets dropped by kernel

No idea who 172.58.43.170 is;  it changes every attempt and it's not my phone.  
Maybe some TMobile interlocutor.  So the checksum is Ok, the packet length is 
736 bytes, and payload is 708.

Same router, same session, inside interface:

# tcpdump -vv -i eth1 'udp port 500 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - 
((udp[12]&0xf0)>>2)) != 0)'
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 
bytes
08:51:01.009360 IP (tos 0x0, ttl 54, id 4126, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > 192.168.111.16.isakmp: [udp sum ok] isakmp 0.0 msgid 
21202208 cookie 645eed11->82343c00:
08:51:02.890010 IP (tos 0x0, ttl 54, id 4127, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > 192.168.111.16.isakmp: [udp sum ok] isakmp 0.0 msgid 
21202208 cookie 645eed11->82343c00:
08:51:05.704159 IP (tos 0x0, ttl 54, id 4128, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > 192.168.111.16.isakmp: [udp sum ok] isakmp 0.0 msgid 
21202208 cookie 645eed11->82343c00:
08:51:09.664003 IP (tos 0x0, ttl 54, id 4129, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > 192.168.111.16.isakmp: [udp sum ok] isakmp 0.0 msgid 
21202208 cookie 645eed11->82343c00:
08:51:15.147956 IP (tos 0x0, ttl 54, id 4130, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > 192.168.111.16.isakmp: [udp sum ok] isakmp 0.0 msgid 
21202208 cookie 064f3d9f->aeee8891:
^C
5 packets captured
6 packets received by filter
0 packets dropped by kernel

Now the whole packet is encapsulated (736 bytes), it seems to be a port 500 
packet and the checksum is Ok.

Here's looking at it coming in to the destination IPSec gateway:

# tcpdump -vv -i eth0 'udp port 500 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - 
((udp[12]&0xf0)>>2)) != 0)'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 
bytes
08:51:01.009581 IP (tos 0x0, ttl 54, id 4126, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > zeta.darkmatter.org.isakmp: [udp sum ok] isakmp 0.0 
msgid 21202208 cookie 645eed11->82343c00:
08:51:02.890141 IP (tos 0x0, ttl 54, id 4127, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > zeta.darkmatter.org.isakmp: [udp sum ok] isakmp 0.0 
msgid 21202208 cookie 645eed11->82343c00:
08:51:05.704507 IP (tos 0x0, ttl 54, id 4128, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > zeta.darkmatter.org.isakmp: [udp sum ok] isakmp 0.0 
msgid 21202208 cookie 645eed11->82343c00:
08:51:09.664215 IP (tos 0x0, ttl 54, id 4129, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > zeta.darkmatter.org.isakmp: [udp sum ok] isakmp 0.0 
msgid 21202208 cookie 645eed11->82343c00:
08:51:15.148127 IP (tos 0x0, ttl 54, id 4130, offset 0, flags [DF], proto UDP 
(17), length 736)
172.58.43.170.60925 > zeta.darkmatter.org.isakmp: [udp sum ok] isakmp 0.0 
msgid 21202208 cookie 064f3d9f->aeee8891:
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel

The packet length is still 736, the port is 500, and checksum is Ok.  These all 
are on the same attempt to communicate and there doesn't seem to be any 
molestation in this chain.  But this seems to be before it is decapsulated.

Libreswan is supposed to automatically handle DNAT-T and clearly it does as it 

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

> On 01/06/2018 04:07 PM, Colony.three via Shorewall-users wrote:
>
>>>  Original Message 
>>> Subject: Re: [Shorewall-users] IPSec Tunneling
>>> Local Time: January 5, 2018 3:41 PM
>>> UTC Time: January 5, 2018 11:41 PM
>>> From: colony.th...@protonmail.ch
>>> To: Shorewall Users shorewall-users@lists.sourceforge.net
>>>
>>>> On 01/05/2018 03:02 PM, Colony.three via Shorewall-users wrote:
>>>>
>>>> On 01/05/2018 02:25 PM, Colony.three via Shorewall-users wrote:
>>>>
>>>> |I'm trying to change the listening port of Libreswan using
>>>> these DNAT entries in rules: DNATnet
>>>> local:192.168.1.16:500  udp  -  5500DNAT
>>>> net local:192.168.1.16  udp  ipsec-nat-t  -
>>>>  ... but this results in the below DROPS.  Rather than
>>>> forwarding the packets to that IP:port, it blocks them as
>>>> destined for the $FW.  I don't understand why?  IPSEC
>>>> connects fine when I don't try to change port 500. Also can I
>>>> combine these two DNAT lines?  Or would that push everything
>>>> into 500? [53533.057543] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00
>>>> SRC=172.58.46.201 DST=50.35.109.212 LEN=736 TOS=0x00
>>>> PREC=0x00 TTL=55 ID=11170 DF PROTO=UDP SPT=20563 DPT=65500
>>>> LEN=716 [53534.973338] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00
>>>> SRC=172.58.46.201 DST=50.35.109.212 LEN=736 TOS=0x00
>>>> PREC=0x00 TTL=55 ID=11171 DF PROTO=UDP SPT=20563 DPT=65500
>>>> LEN=716 [53537.760649] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00
>>>> SRC=172.58.46.201 DST=50.35.109.212 LEN=736 TOS=0x00
>>>> PREC=0x00 TTL=55 ID=11172 DF PROTO=UDP SPT=20563 DPT=65500
>>>> LEN=716 [53541.706546] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00
>>>> SRC=172.58.46.201 DST=50.35.109.212 LEN=736 TOS=0x00
>>>> PREC=0x00 TTL=55 ID=11173 DF PROTO=UDP SPT=20563 DPT=65500
>>>> LEN=716   Install the conntrack utility and run 'conntrack
>>>> -F' and try again.   -Tom |
>>>>
>>>> Thanks, but same DROPs.  conntrack -F seemed to just hang, but when I
>>>> added the tables 'conntrack' and 'expect', it flushed immediately.
>>>> [56184.041321] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11427 DF
>>>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>>>> [56185.906421] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11428 DF
>>>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>>>> [56188.729401] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11429 DF
>>>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>>>>
>>>>
>>>>
>>>> The DESTINATION port is 5500, not the SOURCE port. So your rules
>>>> need:
>>>>
>>>> DNAT net local:192.168.1.16:500 udp 5500 - 
>>>> DNAT net local:192.168.1.16 udp ipsec-nat-t - 
>>>>
>>>> -Tom
>>>
>>> Ah, so true.  Now no more firewall messages, neither at the router nor
>>> the gateway, but still no connect with the changed port, but connect
>>> with 500.  Nothing in /var/log/messages, and the only indication is in
>>> /var/log/secure . (below)
>>> I don't hope for help from you with Libreswan -- you've been more than
>>> generous with the (undeserving) Strongswan.  But if you see what might
>>> be wrong, input is appreciated.
>>> /var/log/secure
>>> Jan  5 15:28:41 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan  5 15:28:41 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> Received packet with mangled IKE header - dropped
>>> Jan  5 15:28:43 zeta pluto[54167]: packet from 172.58.46.194:42614:
>>> length of ISAKMP Message is smaller than minimum
>>> Jan  5 15:28:4

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

>  Original Message 
> Subject: Re: [Shorewall-users] IPSec Tunneling
> Local Time: January 5, 2018 3:41 PM
> UTC Time: January 5, 2018 11:41 PM
> From: colony.th...@protonmail.ch
> To: Shorewall Users <shorewall-users@lists.sourceforge.net>
>
>> On 01/05/2018 03:02 PM, Colony.three via Shorewall-users wrote:
>>
>>> On 01/05/2018 02:25 PM, Colony.three via Shorewall-users wrote:
>>>
>>>> I'm trying to change the listening port of Libreswan using these DNAT
>>>> entries in rules:
>>>> DNATnet local:192.168.1.16:500  udp  -
>>>> 5500   
>>>> DNATnet local:192.168.1.16  udp
>>>> ipsec-nat-t  -
>>>> 
>>>> ... but this results in the below DROPS.  Rather than forwarding the
>>>> packets to that IP:port, it blocks them as destined for the $FW.  I
>>>> don't understand why?  IPSEC connects fine when I don't try to change
>>>> port 500.
>>>> Also can I combine these two DNAT lines?  Or would that push
>>>> everything
>>>> into 500?
>>>> [53533.057543] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11170 DF
>>>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>>>> [53534.973338] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11171 DF
>>>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>>>> [53537.760649] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11172 DF
>>>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>>>> [53541.706546] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11173 DF
>>>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>>>>
>>>>
>>>> Install the conntrack utility and run 'conntrack -F' and try again.
>>>>
>>>> -Tom
>>>
>>> Thanks, but same DROPs.  conntrack -F seemed to just hang, but when I
>>> added the tables 'conntrack' and 'expect', it flushed immediately.
>>> [56184.041321] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11427 DF
>>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>>> [56185.906421] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11428 DF
>>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>>> [56188.729401] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11429 DF
>>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>>
>> The DESTINATION port is 5500, not the SOURCE port. So your rules need:
>>
>> DNAT net local:192.168.1.16:500 udp 5500 - 
>> DNAT net local:192.168.1.16 udp ipsec-nat-t - 
>>
>> -Tom
>
> Ah, so true.  Now no more firewall messages, neither at the router nor the 
> gateway, but still no connect with the changed port, but connect with 500.  
> Nothing in /var/log/messages, and the only indication is in /var/log/secure . 
> (below)
>
> I don't hope for help from you with Libreswan -- you've been more than 
> generous with the (undeserving) Strongswan.  But if you see what might be 
> wrong, input is appreciated.
>
> /var/log/secure
> Jan  5 15:28:41 zeta pluto[54167]: packet from 172.58.46.194:42614: length of 
> ISAKMP Message is smaller than minimum
> Jan  5 15:28:41 zeta pluto[54167]: packet from 172.58.46.194:42614: Received 
> packet with mangled IKE header - dropped
> Jan  5 15:28:43 zeta pluto[54167]: packet from 172.58.46.194:42614: length of 
> ISAKMP Message is smaller than minimum
> Jan  5 15:28:43 zeta pluto[54167]: packet from 172.58.46.194:42614: Received 
> packet with mangled IKE header - dropped
> Jan  5 15:28:46 zeta pluto[54167]: packet from 172.58.46.194:42614: length of 
> ISAKMP Message is smaller than minimum
> Jan  5 15:28:46 zeta pluto[54167]: packet from 172.58.46.194:42614: Received 
> packet with mangled IKE header - dropped
> Jan  5

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

> On 01/05/2018 03:02 PM, Colony.three via Shorewall-users wrote:
>
>> On 01/05/2018 02:25 PM, Colony.three via Shorewall-users wrote:
>>
>>> I'm trying to change the listening port of Libreswan using these DNAT
>>> entries in rules:
>>> DNATnet local:192.168.1.16:500  udp  -
>>> 5500   
>>> DNATnet local:192.168.1.16  udp
>>> ipsec-nat-t  -
>>> 
>>> ... but this results in the below DROPS.  Rather than forwarding the
>>> packets to that IP:port, it blocks them as destined for the $FW.  I
>>> don't understand why?  IPSEC connects fine when I don't try to change
>>> port 500.
>>> Also can I combine these two DNAT lines?  Or would that push
>>> everything
>>> into 500?
>>> [53533.057543] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11170 DF
>>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>>> [53534.973338] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11171 DF
>>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>>> [53537.760649] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11172 DF
>>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>>> [53541.706546] Shorewall:net-fw:DROP:IN=eth0 OUT=
>>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11173 DF
>>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>>>
>>>
>>> Install the conntrack utility and run 'conntrack -F' and try again.
>>>
>>> -Tom
>>
>> Thanks, but same DROPs.  conntrack -F seemed to just hang, but when I
>> added the tables 'conntrack' and 'expect', it flushed immediately.
>> [56184.041321] Shorewall:net-fw:DROP:IN=eth0 OUT=
>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11427 DF
>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>> [56185.906421] Shorewall:net-fw:DROP:IN=eth0 OUT=
>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11428 DF
>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>> [56188.729401] Shorewall:net-fw:DROP:IN=eth0 OUT=
>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11429 DF
>> PROTO=UDP SPT=3196 DPT=5500 LEN=716
>
> The DESTINATION port is 5500, not the SOURCE port. So your rules need:
>
> DNAT net local:192.168.1.16:500 udp 5500 - 
>
> DNAT net local:192.168.1.16 udp ipsec-nat-t - 
>
> -Tom

Ah, so true.  Now no more firewall messages, neither at the router nor the 
gateway, but still no connect with the changed port, but connect with 500.  
Nothing in /var/log/messages, and the only indication is in /var/log/secure . 
(below)

I don't hope for help from you with Libreswan -- you've been more than generous 
with the (undeserving) Strongswan.  But if you see what might be wrong, input 
is appreciated.

/var/log/secure
Jan  5 15:28:41 zeta pluto[54167]: packet from 172.58.46.194:42614: length of 
ISAKMP Message is smaller than minimum
Jan  5 15:28:41 zeta pluto[54167]: packet from 172.58.46.194:42614: Received 
packet with mangled IKE header - dropped
Jan  5 15:28:43 zeta pluto[54167]: packet from 172.58.46.194:42614: length of 
ISAKMP Message is smaller than minimum
Jan  5 15:28:43 zeta pluto[54167]: packet from 172.58.46.194:42614: Received 
packet with mangled IKE header - dropped
Jan  5 15:28:46 zeta pluto[54167]: packet from 172.58.46.194:42614: length of 
ISAKMP Message is smaller than minimum
Jan  5 15:28:46 zeta pluto[54167]: packet from 172.58.46.194:42614: Received 
packet with mangled IKE header - dropped
Jan  5 15:28:50 zeta pluto[54167]: packet from 172.58.46.194:42614: length of 
ISAKMP Message is smaller than minimum
Jan  5 15:28:50 zeta pluto[54167]: packet from 172.58.46.194:42614: Received 
packet with mangled IKE header - dropped
Jan  5 15:28:55 zeta pluto[54167]: packet from 172.58.46.194:42614: length of 
ISAKMP Message is smaller than minimum
Jan  5 15:28:55 zeta pluto[54167]: packet from 172.58.46.194:42614: Received 
packet with mangled IKE header - dropped
Jan  5 15:31:54 zeta pluto[54167]: packet from 172.58.43.178:19924: length of 
ISAKMP Message is smaller than minimum
Jan  5 15:31:54 zeta pluto[54167]: packet from 172.58.43.17

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

On 01/05/2018 02:25 PM, Colony.three via Shorewall-users wrote:

>> I'm trying to change the listening port of Libreswan using these DNAT
>> entries in rules:
>> DNATnet local:192.168.1.16:500  udp  -  5500   
>> DNATnet local:192.168.1.16  udp  ipsec-nat-t  -
>> 
>> ... but this results in the below DROPS.  Rather than forwarding the
>> packets to that IP:port, it blocks them as destined for the $FW.  I
>> don't understand why?  IPSEC connects fine when I don't try to change
>> port 500.
>> Also can I combine these two DNAT lines?  Or would that push everything
>> into 500?
>> [53533.057543] Shorewall:net-fw:DROP:IN=eth0 OUT=
>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11170 DF
>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>> [53534.973338] Shorewall:net-fw:DROP:IN=eth0 OUT=
>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11171 DF
>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>> [53537.760649] Shorewall:net-fw:DROP:IN=eth0 OUT=
>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11172 DF
>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>> [53541.706546] Shorewall:net-fw:DROP:IN=eth0 OUT=
>> MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201
>> DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11173 DF
>> PROTO=UDP SPT=20563 DPT=65500 LEN=716
>
> Install the conntrack utility and run 'conntrack -F' and try again.
>
> -Tom

Thanks, but same DROPs.  conntrack -F seemed to just hang, but when I added the 
tables 'conntrack' and 'expect', it flushed immediately.

[56184.041321] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11427 DF PROTO=UDP 
SPT=3196 DPT=5500 LEN=716
[56185.906421] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11428 DF PROTO=UDP 
SPT=3196 DPT=5500 LEN=716
[56188.729401] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11429 DF PROTO=UDP 
SPT=3196 DPT=5500 LEN=716--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

On 12/14/2017 02:55 PM, cac...@quantum-sci.com wrote:

>> On 12/14/2017 02:50 PM, Tom Eastep wrote:
>>
>>> On 12/14/2017 02:28 PM, Colony.three via Shorewall-users wrote:
>>>
>>>> I have a VM which is the LAN router, and another VM in the LAN which
>>>> is the ipsec gateway. (strongswan)
>>>> I'm not fully understanding the guide here;
>>>> http://www.shorewall.net/IPSEC-2.6.html
>>>>
>>>> - Does this still apply to kernel 4.*?  There isn't a
>>>> http://www.shorewall.net/IPSEC.html
>>>> http://www.shorewall.net/IPSEC-2.6.html
>>>> - It doesn't say to set up DNAT on the router.  How does the router
>>>> know where the ipsec gateway is?
>>>> - On the laptop, tunnels should be set as:  ipsec net 206.162.148.9
>>>> vpn.  But what is that IP?  The dynamic IP of the laptop, or the
>>>> outside interface of the remote router?
>>>> - If the latter, is there a way in the laptop's tunnels to, instead of
>>>> an explicit IP, do a DNS request, to get that remote IP?
>>>> - Wouldn't I need to set up DNAT in and SNAT out for ports 500 and 4500?
>>>> - How do I enable protocols 50 & 51?  Would that be on one or both ports?
>>>
>>> There is no Shorewall document that describes configuring the local
>>> responding endpoint on a system behind the Shorewall hosts. Such a
>>> configuration is of very limited utility, since it only allows remote
>>> access to the local endpoint host, and not to any other local host
>>> (including the Shorewall host). So the IPSEC-2.6 document only covers
>>> the case where the Shorewall host is the local responding endpoint.
>>> If you really want to configure a host behind the firewall as your
>>> local responding endpoint, then you must:
>>> a) Configure IPSEC to use Nat Traversal.
>>> b) DNAT UDP 500 and 4500 to the local endpoint host.
>>> You don't need to worry about the other protocols, as they will
>>> be encapsulated within UDP port 4500 packets.
>>> -Tom
>>
>> Thanks.  The reason I have this structure in mind is, if ipsec is
>> compromised, I want the ne'er-do-well to end up in a benign VM, -not-
>> the router.
>> You're saying though if I do it this way, then the remote laptop can not
>> access machines on the LAN other than the gateway?  Surely there's an
>> ipsec setting.
>
> No. You might be able to work around this by using SNAT on the endpoint
> system, such that all traffic from the remote laptop through the local
> endpoint is made to look like it came from the local endpoint host
> itself. Like all NAT, that's a bit of a hack. You wouldn't need
> Shorewall on the local endpoint for that; you could simply execute:
>
> iptables -t nat -A POSTROUTING -j MASQUERADE
>
> during boot.
>
> -Tom

I have Shorewall running on all machines.  :j

Is there a way to do this in Shorewall?  The masq file?

I have  net.ipv4.ip_forward = 1 set in /etc/syscfg.conf.

I guess this would allow packets to be masqueraded through the Libreswan 
gateway to the rest of the LAN -- but out the same interface? (There is only 
one in this VM)

If masquerading can happen out the same interface, does this mean packets can 
also go out the LAN router to The The Internets? (Which is the goal)--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

> I'm trying to change the listening port of Libreswan using these DNAT entries 
> in rules:
> DNATnet local:192.168.1.16:500  udp  -  5500   
> DNATnet local:192.168.1.16  udp  ipsec-nat-t  -  
>
> ... but this results in the below DROPS.  Rather than forwarding the packets 
> to that IP:port, it blocks them as destined for the $FW.  I don't understand 
> why?  IPSEC connects fine when I don't try to change port 500.
>
> Also can I combine these two DNAT lines?  Or would that push everything into 
> 500?

Check that.  It results in these DROPS:
[53533.057543] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11170 DF PROTO=UDP 
SPT=20563 DPT=5500 LEN=716
[53534.973338] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11171 DF PROTO=UDP 
SPT=20563 DPT=5500 LEN=716
[53537.760649] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11172 DF PROTO=UDP 
SPT=20563 DPT=5500 LEN=716
[53541.706546] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11173 DF PROTO=UDP 
SPT=20563 DPT=5500 LEN=716--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

I'm trying to change the listening port of Libreswan using these DNAT entries 
in rules:
DNATnet local:192.168.1.16:500  udp  -  5500   
DNATnet local:192.168.1.16  udp  ipsec-nat-t  -  

... but this results in the below DROPS.  Rather than forwarding the packets to 
that IP:port, it blocks them as destined for the $FW.  I don't understand why?  
IPSEC connects fine when I don't try to change port 500.

Also can I combine these two DNAT lines?  Or would that push everything into 
500?

[53533.057543] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11170 DF PROTO=UDP 
SPT=20563 DPT=65500 LEN=716
[53534.973338] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11171 DF PROTO=UDP 
SPT=20563 DPT=65500 LEN=716
[53537.760649] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11172 DF PROTO=UDP 
SPT=20563 DPT=65500 LEN=716
[53541.706546] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:e6:0a:80:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.46.201 
DST=50.35.109.212 LEN=736 TOS=0x00 PREC=0x00 TTL=55 ID=11173 DF PROTO=UDP 
SPT=20563 DPT=65500 LEN=716--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DNAT Port Changing

[Colony.three via Shorewall-users]

> On 01/03/2018 12:55 PM, Colony.three via Shorewall-users wrote:
>
>> I have a router which is a KVM VM running CentOS7.  Then I have a
>> LibreSwan gateway, which is another VM in the LAN, also running CentOS7.
>> There are 100,0 bots out there trying to get in to any and all
>> ports, ready and armed with the right known vulns and 0-days for the
>> normal ports, so I'd like to change ipsec 500 to something else.
>> (changing 4500 is inadvisable for kernel reasons)
>> Libreswan can't change listening ports so am I on the right track in the
>> router doing it like this?
>> DNAT  net   loc:192.168.1.15:500udp63500
>> (the ipsec gateway is 192.168.1.15, and the outside interface of the
>> router is eth0)
>> Reason I ask is in the docs, that 63500 column is labeled  DPORT,
>> whereas it's the source port from the router's PoV.  ... although it's
>> the destination port from the initiator's PoV.
>
> There is an SPORT column between DPORT and ORIGDEST. If it is actually
> the source port, then you need '-' in the DEST column and 63500 in the
> SPORT column.
>
> -Tom

Oh, Ok thanks.
DNAT  net   loc:192.168.1.15:500udp-  63500--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] DNAT Port Changing

[Colony.three via Shorewall-users]

I have a router which is a KVM VM running CentOS7.  Then I have a LibreSwan 
gateway, which is another VM in the LAN, also running CentOS7.

There are 100,0 bots out there trying to get in to any and all ports, ready 
and armed with the right known vulns and 0-days for the normal ports, so I'd 
like to change ipsec 500 to something else. (changing 4500 is inadvisable for 
kernel reasons)

Libreswan can't change listening ports so am I on the right track in the router 
doing it like this?
DNAT  net   loc:192.168.1.15:500udp63500
(the ipsec gateway is 192.168.1.15, and the outside interface of the router is 
eth0)

Reason I ask is in the docs, that 63500 column is labeled  DPORT, whereas it's 
the source port from the router's PoV.  ... although it's the destination port 
from the initiator's PoV.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Strongswan is Busted

[Colony.three via Shorewall-users]

Am 28.12.2017 um 22:51 schrieb Colony.three via Shorewall-users:

>> I am at a complete loss.  I know this is not the Strongswan forum,
>
> Yes it is not and Tom in his incredible helpfulness tried to get you
> through shallows of networking.
>
> Now it appears that you had problems understanding the build process of
> certificates and the basic set up of IPSEC. Indeed this is not a trivial
> task but needs to be addressed in the strongswan list/forum.
>
> but
>
>> they are unresponsive with all methods of communication -- and now I see
>> why.  My personal opinion is that Strongswan is only /rumored/ to work,
>> but actually works in the sense that a puppet does.
>
> I doubt they do see it your way. There is a user list for strongswan and
> there are actually people using it.

Is condescension your specialty, Erich?  I notice that you do not have 
Strongswan working.  Until you do, your opinion is not notable, much less 
helpful.

I recognize and am grateful for Tom's efforts.  I did not intend my email to 
reflect negatively on him.  I am just saying that enough is enough, warned 
others off, and asked for recommendations.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Strongswan is Busted

[Colony.three via Shorewall-users]

I am at a complete loss.  I know this is not the Strongswan forum, but they are 
unresponsive with all methods of communication -- and now I see why.  My 
personal opinion is that Strongswan is only rumored to work, but actually works 
in the sense that a puppet does.

Sure Tom says he got it to work, but I followed his [exact 
process](https://wiki.strongswan.org/projects/strongswan/wiki/SimpleCA) and it 
does not work for me.  The Scientific Method means that a procedure must be 
repeatable.  And, I have never heard of anyone besides Tom who says he's gotten 
Strongswan actually working.

I banged my head on the wall for two weeks with it says it 'can't match the 
incoming configuration'.  Yesterday I discovered that, although the SS devs put 
-in- the subdirs strongswan.d and ipsec.d (where local configs are supposed to 
go, according to generally accepted standard)...  .conf files in these are not 
actually picked up by SS init!  Well, at least strongswan.conf and ipsec.conf 
are not picked up in these subdirs.

So when I put my modifications in the cardinal /etc/strongswan/strongswan.conf 
and ipsec.conf, I started reaching my daemon from the remote phone.  But now 
the daemon is completely unresponsive.  Inconsolable.  There is absolutely 
nothing in the log WRT the connexion, even with logging set to the max: 
charondebug="cfg 4, dmn 4, ike 4, net 4"

I can see the attempts coming in to the ipsec gateway with tcpdump...  but 
there is no response from the charon daemon.  It's not interested, or deaf, or 
on vacation.

I had been building keys of 4096 bits, so I made all new CA and keys with the 
default of 2048.  Absolutely no change.

Now; I've run Linux exclusively for 20 years, and I am hyper-persistent well 
past the point of unreasonableness.  But there comes a point of 'crazy' and 
that is time to give up.  So I am open to suggestion on what VPN software 
others are -actually- able to get working, in practice, for real.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DNAT and UDP

[Colony.three via Shorewall-users]

> As one of the Libreswan authors I'd note it's "Libreswan" - no capital
> letters in the middle of the name, please.
>
> When suggesting manual keying, please note it is horribly insecure and should 
> not be used:
>
> https://tools.ietf.org/html/rfc8221#section-3
>
> Tuomo Soini t...@foobar.fi

Thanks for the info Tuomo,

Am I understanding correctly that Libreswan does -not- do NAT-T properly?  If 
so, is there some way to mitigate this?--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

> Hm, I am not seeing any evidence that the daemon is picking up my
> /etc/strongswan/strongswan.d/bills-strongswan.conf  nor
> /etc/strongswan/ipdec.d/bills-ipsec.conf .  But then, it's not noting yours 
> either, assuming you have your own ipsec.conf and strongswan.conf .
>
> These are my main configuration files.  In my case there's virtually nothing 
> in /etc/strongswan/strongswan.conf and /etc/strongswan/ipsec.conf .
>
> Not picking up my config files would explain the consistent error I'm getting 
> and why almost no one else seems to have this.
>
> I also see that you're using .der certs and keys.  I don't understand this 
> as, before you can pile the key and cert into a .p12 file (which is required 
> by the Android app), they must be in .pem format.  And even when I copy my 
> user's cert to the phone and import using the CACert interface, the cert ends 
> up in Imported, and not in User.
>
> I don't understand what's wrong.

Ok, now I am starting to get errors that make sense.

I have moved my strongswan.d/*.conf and ipsec.d/*.conf files (where they are 
SUPPOSED to be) to /etc/strongswan/strongswan.conf and ipsec.conf respectively. 
 Looks like the devs have not implemented these PROPER .d subdirs like they 
should have. (GDammit) That's a loss of confidence in them...

Now startup looks like this:

Dec 27 16:17:37 zeta strongswan: charon stopped after 200 ms
Dec 27 16:17:37 zeta strongswan: ipsec starter stopped
Dec 27 16:17:37 zeta systemd: Started strongSwan IPsec IKEv1/IKEv2 daemon using 
ipsec.conf.
Dec 27 16:17:37 zeta systemd: Starting strongSwan IPsec IKEv1/IKEv2 daemon 
using ipsec.conf...
Dec 27 16:17:37 zeta strongswan: Starting strongSwan 5.5.3 IPsec [starter]...
Dec 27 16:17:37 zeta charon: 00[DMN] Starting IKE charon daemon (strongSwan 
5.5.3, Linux 4.13.0-1.el7.elrepo.x86_64, x86_64)
Dec 27 16:17:37 zeta charon: 00[LIB] openssl FIPS mode(2) - enabled
Dec 27 16:17:38 zeta charon: 00[CFG] loading ca certificates from 
'/etc/strongswan/ipsec.d/cacerts'
Dec 27 16:17:38 zeta charon: 00[CFG]   loaded ca certificate "C=US, 
O=QuantumEquities, CN=QuantumCA" from 
'/etc/strongswan/ipsec.d/cacerts/cacert.pem'
Dec 27 16:17:38 zeta charon: 00[CFG] loading aa certificates from 
'/etc/strongswan/ipsec.d/aacerts'
Dec 27 16:17:38 zeta charon: 00[CFG] loading ocsp signer certificates from 
'/etc/strongswan/ipsec.d/ocspcerts'
Dec 27 16:17:38 zeta charon: 00[CFG] loading attribute certificates from 
'/etc/strongswan/ipsec.d/acerts'
Dec 27 16:17:38 zeta charon: 00[CFG] loading crls from 
'/etc/strongswan/ipsec.d/crls'
Dec 27 16:17:38 zeta charon: 00[CFG] loading secrets from 
'/etc/strongswan/ipsec.secrets'
Dec 27 16:17:38 zeta charon: 00[CFG]   loaded RSA private key from 
'/etc/strongswan/ipsec.d/private/billsKey.pem'
Dec 27 16:17:38 zeta charon: 00[LIB] loaded plugins: charon aes des rc2 sha2 
sha1 md4 md5 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs8 
pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 xcbc cmac 
hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke 
vici updown eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap 
xauth-generic xauth-eap xauth-pam xauth-noauth dhcp unity
Dec 27 16:17:38 zeta charon: 00[JOB] spawning 16 worker threads
Dec 27 16:17:38 zeta strongswan: charon (32350) started after 40 ms
Dec 27 16:17:38 zeta charon: 05[CFG] received stroke: add connection 'ipv4'
Dec 27 16:17:38 zeta charon: 05[CFG] left nor right host is our side, assuming 
left=local
Dec 27 16:17:38 zeta charon: 05[CFG] adding virtual IP address pool 
192.168.11.0/24
Dec 27 16:17:38 zeta charon: 05[CFG]   loaded certificate "C=US, O=Quantum, 
CN=cac...@quantum-equities.com" from 'billsCert.pem'
Dec 27 16:17:38 zeta charon: 05[CFG] added configuration 'ipv4'

NOW I can make some frickin' gol' damned SENSE out of this.  I'll resume 
tomorrow, when I am less drunk.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

>  Original Message 
> Subject: Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)
> Local Time: December 27, 2017 3:51 PM
> UTC Time: December 27, 2017 11:51 PM
> From: teas...@shorewall.net
> To: shorewall-users@lists.sourceforge.net
>
> On 12/27/2017 03:46 PM, Colony.three via Shorewall-users wrote:
>
>>>  Original Message 
>>> Subject: Re: [Shorewall-users] UDP Getting Blocked When Unblocked
>>> (StrongSwan)
>>> Local Time: December 27, 2017 3:31 PM
>>> UTC Time: December 27, 2017 11:31 PM
>>> From: teas...@shorewall.net
>>> To: shorewall-users@lists.sourceforge.net
>>> On 12/27/2017 03:27 PM, Colony.three via Shorewall-users wrote:
>>>
>>> Dec 27 15:20:49 zeta charon: 00[CFG] loading secrets from
>>> '/etc/strongswan/ipsec.secrets'
>>> Dec 27 15:20:49 zeta charon: 00[LIB]   opening
>>> '/etc/strongswan/ipsec.d/private/quantumKey.pem' failed: No such file
>>> or directory
>>> Dec 27 15:20:49 zeta charon: 00[LIB] building CRED_PRIVATE_KEY - RSA
>>> failed, tried 4 builders
>>> Dec 27 15:20:49 zeta charon: 00[CFG]   loading private key from
>>> '/etc/strongswan/ipsec.d/private/quantumKey.pem' failed
>>>
>>>
>>> The above messages certainly aren't good!
>>>
>>> -Tom
>>
>> Understand.  I was in the middle of something as noted in my prior
>> ().  Here it is again stabilized but still the same problem as all along:
>> Dec 27 15:38:59 zeta strongswan: ipsec starter stopped
>> Dec 27 15:39:02 zeta systemd: Started strongSwan IPsec IKEv1/IKEv2
>> daemon using ipsec.conf.
>> Dec 27 15:39:02 zeta systemd: Starting strongSwan IPsec IKEv1/IKEv2
>> daemon using ipsec.conf...
>> Dec 27 15:39:02 zeta strongswan: Starting strongSwan 5.5.3 IPsec
>> [starter]...
>> Dec 27 15:39:02 zeta strongswan: !! Your strongswan.conf contains
>> manual plugin load options for charon.
>> Dec 27 15:39:02 zeta strongswan: !! This is recommended for experts
>> only, see
>> Dec 27 15:39:02 zeta strongswan: !!
>> http://wiki.strongswan.org/projects/strongswan/wiki/PluginLoad
>> Dec 27 15:39:02 zeta charon: 00[DMN] Starting IKE charon daemon
>> (strongSwan 5.5.3, Linux 4.13.0-1.el7.elrepo.x86_64, x86_64)
>> Dec 27 15:39:02 zeta charon: 00[CFG] loading ca certificates from
>> '/etc/strongswan/ipsec.d/cacerts'
>> Dec 27 15:39:02 zeta charon: 00[CFG]   loaded ca certificate "C=US,
>> O=QuantumEquities, CN=QuantumCA" from
>> '/etc/strongswan/ipsec.d/cacerts/cacert.pem'
>> Dec 27 15:39:02 zeta charon: 00[CFG] loading aa certificates from
>> '/etc/strongswan/ipsec.d/aacerts'
>> Dec 27 15:39:02 zeta charon: 00[CFG] loading ocsp signer certificates
>> from '/etc/strongswan/ipsec.d/ocspcerts'
>> Dec 27 15:39:02 zeta charon: 00[CFG] loading attribute certificates
>> from '/etc/strongswan/ipsec.d/acerts'
>> Dec 27 15:39:02 zeta charon: 00[CFG] loading crls from
>> '/etc/strongswan/ipsec.d/crls'
>> Dec 27 15:39:02 zeta charon: 00[CFG] loading secrets from
>> '/etc/strongswan/ipsec.secrets'
>> Dec 27 15:39:02 zeta charon: 00[CFG]   loaded RSA private key from
>> '/etc/strongswan/ipsec.d/private/carlsKey.pem'
>> Dec 27 15:39:02 zeta charon: 00[LIB] loaded plugins: charon random
>> nonce aes sha1 sha2 pem pkcs1 gmp x509 curl revocation hmac stroke
>> kernel-netlink socket-default updown
>> Dec 27 15:39:02 zeta charon: 00[JOB] spawning 16 worker threads
>> Dec 27 15:39:02 zeta strongswan: charon (32155) started after 20 ms
>
> In by case, it goes on...
>
> loaded plugins: charon aesni aes rc2 sha2 sha1 md5 random nonce x509
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey
> pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve
> socket-default connmark stroke updown
> Dec 27 15:04:56 irssi charon: 00[LIB] dropped capabilities, running as
> uid 0, gid 0
> Dec 27 15:04:56 irssi charon: 00[JOB] spawning 16 worker threads
> Dec 27 15:04:56 irssi charon: 05[CFG] received stroke: add connection 'ipv4'
> Dec 27 15:04:56 irssi charon: 05[CFG] adding virtual IP address pool
> 172.20.3.0/24
> Dec 27 15:04:56 irssi charon: 05[CFG]   loaded certificate "C=US,
> O=Shorewall, CN=irssi" from 'irssiCert.der'
> Dec 27 15:04:56 irssi charon: 05[CFG] added configuration 'ipv4'
> Dec 27 15:04:56 irssi charon: 07[CFG] received stroke: add connection 'ipv6'
> Dec 27 15:04:56 irssi charon: 07[CFG] virtual IP pool too large,
> limiting to 2601:601:a000:16f7::/97
> Dec 27 15:04:56 irssi charon: 07[CFG] adding virtual IP address pool
>

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

>  Original Message 
> Subject: Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)
> Local Time: December 27, 2017 3:31 PM
> UTC Time: December 27, 2017 11:31 PM
> From: teas...@shorewall.net
> To: shorewall-users@lists.sourceforge.net
>
> On 12/27/2017 03:27 PM, Colony.three via Shorewall-users wrote:
>
>> Dec 27 15:20:49 zeta charon: 00[CFG] loading secrets from
>> '/etc/strongswan/ipsec.secrets'
>> Dec 27 15:20:49 zeta charon: 00[LIB]   opening
>> '/etc/strongswan/ipsec.d/private/quantumKey.pem' failed: No such file
>> or directory
>> Dec 27 15:20:49 zeta charon: 00[LIB] building CRED_PRIVATE_KEY - RSA
>> failed, tried 4 builders
>> Dec 27 15:20:49 zeta charon: 00[CFG]   loading private key from
>> '/etc/strongswan/ipsec.d/private/quantumKey.pem' failed
>
> The above messages certainly aren't good!
>
> -Tom

Understand.  I was in the middle of something as noted in my prior ().  Here it 
is again stabilized but still the same problem as all along:

Dec 27 15:38:59 zeta strongswan: ipsec starter stopped
Dec 27 15:39:02 zeta systemd: Started strongSwan IPsec IKEv1/IKEv2 daemon using 
ipsec.conf.
Dec 27 15:39:02 zeta systemd: Starting strongSwan IPsec IKEv1/IKEv2 daemon 
using ipsec.conf...
Dec 27 15:39:02 zeta strongswan: Starting strongSwan 5.5.3 IPsec [starter]...
Dec 27 15:39:02 zeta strongswan: !! Your strongswan.conf contains manual plugin 
load options for charon.
Dec 27 15:39:02 zeta strongswan: !! This is recommended for experts only, see
Dec 27 15:39:02 zeta strongswan: !! 
http://wiki.strongswan.org/projects/strongswan/wiki/PluginLoad
Dec 27 15:39:02 zeta charon: 00[DMN] Starting IKE charon daemon (strongSwan 
5.5.3, Linux 4.13.0-1.el7.elrepo.x86_64, x86_64)
Dec 27 15:39:02 zeta charon: 00[CFG] loading ca certificates from 
'/etc/strongswan/ipsec.d/cacerts'
Dec 27 15:39:02 zeta charon: 00[CFG]   loaded ca certificate "C=US, 
O=QuantumEquities, CN=QuantumCA" from 
'/etc/strongswan/ipsec.d/cacerts/cacert.pem'
Dec 27 15:39:02 zeta charon: 00[CFG] loading aa certificates from 
'/etc/strongswan/ipsec.d/aacerts'
Dec 27 15:39:02 zeta charon: 00[CFG] loading ocsp signer certificates from 
'/etc/strongswan/ipsec.d/ocspcerts'
Dec 27 15:39:02 zeta charon: 00[CFG] loading attribute certificates from 
'/etc/strongswan/ipsec.d/acerts'
Dec 27 15:39:02 zeta charon: 00[CFG] loading crls from 
'/etc/strongswan/ipsec.d/crls'
Dec 27 15:39:02 zeta charon: 00[CFG] loading secrets from 
'/etc/strongswan/ipsec.secrets'
Dec 27 15:39:02 zeta charon: 00[CFG]   loaded RSA private key from 
'/etc/strongswan/ipsec.d/private/carlsKey.pem'
Dec 27 15:39:02 zeta charon: 00[LIB] loaded plugins: charon random nonce aes 
sha1 sha2 pem pkcs1 gmp x509 curl revocation hmac stroke kernel-netlink 
socket-default updown
Dec 27 15:39:02 zeta charon: 00[JOB] spawning 16 worker threads
Dec 27 15:39:02 zeta strongswan: charon (32155) started after 20 ms--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

> The Cert isn't involved in the IKE_SA_INIT request. Verification of the
> cert occurs in the IKE_AUTH request. What are the messages generated
> when you start your local StrongSwan config?
>
> -Tom

I don't see anything abnormal...  although I do not see it calling 
strongswan.d/bills-strongswan.conf  nor  ipsec.d/bills-ipsec.conf.

/etc/strongswan/strongswan.conf has:
include strongswan.d/*.conf
... but /etc/strongswan/ipsec.conf doesn't have any such thing.

(The missing key is because I was experimenting at that moment)

Dec 27 15:20:43 zeta systemd: Stopped strongSwan IPsec IKEv1/IKEv2 daemon using 
ipsec.conf.
Dec 27 15:20:49 zeta systemd: Started strongSwan IPsec IKEv1/IKEv2 daemon using 
ipsec.conf.
Dec 27 15:20:49 zeta systemd: Starting strongSwan IPsec IKEv1/IKEv2 daemon 
using ipsec.conf...
Dec 27 15:20:49 zeta strongswan: Starting strongSwan 5.5.3 IPsec [starter]...
Dec 27 15:20:49 zeta strongswan: !! Your strongswan.conf contains manual plugin 
load options for charon.
Dec 27 15:20:49 zeta strongswan: !! This is recommended for experts only, see
Dec 27 15:20:49 zeta strongswan: !! 
http://wiki.strongswan.org/projects/strongswan/wiki/PluginLoad
Dec 27 15:20:49 zeta charon: 00[DMN] Starting IKE charon daemon (strongSwan 
5.5.3, Linux 4.13.0-1.el7.elrepo.x86_64, x86_64)
Dec 27 15:20:49 zeta charon: 00[CFG] loading ca certificates from 
'/etc/strongswan/ipsec.d/cacerts'
Dec 27 15:20:49 zeta charon: 00[CFG]   loaded ca certificate "C=US, 
O=QuantumEquities, CN=QuantumCA" from 
'/etc/strongswan/ipsec.d/cacerts/cacert.pem'
Dec 27 15:20:49 zeta charon: 00[CFG] loading aa certificates from 
'/etc/strongswan/ipsec.d/aacerts'
Dec 27 15:20:49 zeta charon: 00[CFG] loading ocsp signer certificates from 
'/etc/strongswan/ipsec.d/ocspcerts'
Dec 27 15:20:49 zeta charon: 00[CFG] loading attribute certificates from 
'/etc/strongswan/ipsec.d/acerts'
Dec 27 15:20:49 zeta charon: 00[CFG] loading crls from 
'/etc/strongswan/ipsec.d/crls'
Dec 27 15:20:49 zeta charon: 00[CFG] loading secrets from 
'/etc/strongswan/ipsec.secrets'
Dec 27 15:20:49 zeta charon: 00[LIB]   opening 
'/etc/strongswan/ipsec.d/private/quantumKey.pem' failed: No such file or 
directory
Dec 27 15:20:49 zeta charon: 00[LIB] building CRED_PRIVATE_KEY - RSA failed, 
tried 4 builders
Dec 27 15:20:49 zeta charon: 00[CFG]   loading private key from 
'/etc/strongswan/ipsec.d/private/quantumKey.pem' failed
Dec 27 15:20:49 zeta charon: 00[LIB] loaded plugins: charon random nonce aes 
sha1 sha2 pem pkcs1 gmp x509 curl revocation hmac stroke kernel-netlink 
socket-default updown
Dec 27 15:20:49 zeta charon: 00[JOB] spawning 16 worker threads
Dec 27 15:20:49 zeta strongswan: charon (32057) started after 20 ms--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

Simple CA is the procedure I've been using too.

>> Dec 27 14:29:54 zeta charon: 05[NET] received packet: from 
>> 172.58.43.66[21321] to 192.168.111.16[500] (704 bytes)
>> Dec 27 14:29:54 zeta charon: 05[ENC] parsed IKE_SA_INIT request 0 [ SA KE No 
>> N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
>> Dec 27 14:29:54 zeta charon: 05[IKE] no IKE config found for 
>> 192.168.111.16...172.58.43.66, sending NO_PROPOSAL_CHOSEN
>> Dec 27 14:29:54 zeta charon: 05[ENC] generating IKE_SA_INIT response 0 [ 
>> N(NO_PROP) ]
>> Dec 27 14:29:54 zeta charon: 05[NET] sending packet: from 
>> 192.168.111.16[500] to 172.58.43.66[21321] (36 bytes)
>>
>> Well NAT-T definitely does not work.  I can not make this work, following 
>> the SimpleCA instructions to a T.  I did import the proper .p12, and 
>> separately the caCert.pem into Imported like you did.  172.58.43.66 has 
>> nothing to do with my phone (100.196.9.93), and I think that is a clue to 
>> the problem.
>>
>> Maybe I should give up and put StrongSwan on the router and let the router 
>> have access to the rest of the LAN.  That just seems like a stupid thing to 
>> do but I simply have not been able to fix this problem after 2 weeks of 
>> trying full time.  I can't believe that this is impossible.
>
> As well, for cert generation I added --san:
> # strongswan pki --pub --in private/quantumKey.pem --type rsa | strongswan 
> pki --issue --cacert certs/caCert.pem --cakey private/caKey.pem --san 
> quantum-equities.com --dn "C=US, O=Quantum, CN=quantum-equities.com" 
> --outform pem > certs/quantumCert.pem
>
> ... and in the SS Android app I put quantum-equities.com in Server Identity 
> like you did.

I've never had any cert end up in User certs, by importing the .p12 using the 
connexion Edit.  Maybe that's the actual problem.

It pretends like it imports the .p12 just fine.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

Simple CA is the procedure I've been using too.

Dec 27 14:29:54 zeta charon: 05[NET] received packet: from 172.58.43.66[21321] 
to 192.168.111.16[500] (704 bytes)
Dec 27 14:29:54 zeta charon: 05[ENC] parsed IKE_SA_INIT request 0 [ SA KE No 
N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Dec 27 14:29:54 zeta charon: 05[IKE] no IKE config found for 
192.168.111.16...172.58.43.66, sending NO_PROPOSAL_CHOSEN
Dec 27 14:29:54 zeta charon: 05[ENC] generating IKE_SA_INIT response 0 [ 
N(NO_PROP) ]
Dec 27 14:29:54 zeta charon: 05[NET] sending packet: from 192.168.111.16[500] 
to 172.58.43.66[21321] (36 bytes)

Well NAT-T definitely does not work.  I can not make this work, following the 
SimpleCA instructions to a T.  I did import the proper .p12, and separately the 
caCert.pem into Imported like you did.  172.58.43.66 has nothing to do with my 
phone (100.196.9.93), and I think that is a clue to the problem.

Maybe I should give up and put StrongSwan on the router and let the router have 
access to the rest of the LAN.  That just seems like a stupid thing to do but I 
simply have not been able to fix this problem after 2 weeks of trying full 
time.  I can't believe that this is impossible.

>  Original Message 
> Subject: Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)
> Local Time: December 24, 2017 2:20 PM
> UTC Time: December 24, 2017 10:20 PM
> From: teas...@shorewall.net
> To: shorewall-users@lists.sourceforge.net
>
> On 12/24/2017 12:59 PM, Tom Eastep wrote:
>
>> On 12/24/2017 12:45 PM, Colony.three via Shorewall-users wrote:
>>
>>>> I saw something similar when I neglected to add a subjectAltName
>>>> (gateway.shorewall.net <http://gateway.shorewall.net>) to the
>>>> local endpoint's cert.
>>>>
>>>> FWIW, I've attached a log extract of a successful SA establishment.
>>>>
>>>> -Tom
>>>
>>> Hm, interesting.  I've consistently used scripts from SomeRandomDude on
>>> The Internets, and indeed it does not provide for subjectAltName.  Good
>>> lead, thanks, I'll look for SS's procedure for generating certs.  There
>>> is just a quagmire haystack of disorganized info out there about this,
>>> which I'll bet quietly defeats 90% of those who try this.
>>> Setting rightsourceip=192.168.11.0/24and restarting SS didn't change
>>> anything.
>>> I've never understood the interplay of IP ranges and addresses between
>>> left and right, as in some cases 'left' always means 'me', whether
>>> setting in local or remote, and in other cases it means as I'd
>>> understood it, 'left' is ipsec gateway and 'right' is remote laptop.
>>> Also I notice that everyone always references the -server- cert and key
>>> in ipsec.conf settings, whereas the StrongSwan Android app will only
>>> accept a .p12 file.  A .p12 file is genned by the RandomDude's scripts
>>> for -user- (as well as cert and key), and it also gens the -server- cert
>>> and key.  So I can only set the -user- cert (.p12) in the Android app.
>>> I'll investigate further.
>>
>> I'm just installing the StrongSwan Android app and will play with it as
>> well.
>
> After a bit of a hassle with certs, I got it working.
>
> a) I used the StrongSwan Simple CA
> (https://wiki.strongswan.org/projects/strongswan/wiki/SimpleCA) to
> generate my certs, with a subjectAltName. The subjectAltName of the
> local endpoint is gateway.shorewall.net. On the Android, that must be
> placed in the Server Identity setting (Advanced Settings). I imported by
> CA cert separately (shows up under 'Imported' on the Android).
>
> b) Local Endpoint Configuration:
>
> conn %default
> ikelifetime=60m
> keylife=20m
> rekeymargin=3m
> keyingtries=3
> keyexchange=ikev2
> authby=pubkey
>
> conn ipv4
> left=70.90.191.121
> leftid=gateway.shorewall.net
>
> leftsubnet=172.20.1.0/24,172.20.2.0/24,70.90.191.122/31,70.90.191.124/31
> leftcert=gatewayCert.der
> right=%any
> rightsourceip=172.20.3.0/24
> rightdns=172.20.1.253
> auto=add
>
> c) Android configuration:
>
> Server: 70.90.191.121
> VPN Type: IKEv2 Certificate
> User certificate: (CN=phone,O=Shorewall,C=US)
> Ca certificate: Imported CA cert
> Profile name: Shorewall IPv4
> Server Identity: gateway.shorewall.net
>
> -Tom
>
> Tom Eastep \ Q: What do you get when you cross a mobster with
> Shoreline, \ an international standard?
> Washington, USA \ A: Someone who makes you an offer you can't
> http://shorewall.org \ understand
> ___
>
> Check out the vibrant tech community on one of

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

> Just as a FYI: I have OpenVPN set up and working on my android phone.
>
> I generated a CA cert and then a cert for my phone using xca (GUI interface).
>
> Bill

Good to know.  I'd originally decided on IPSec because it's universally used in 
business, and is regarded to be the most secure, at least when used with certs. 
 But I have no illusions about how difficult it is.

I can't use LibreSwan as it doesn't play well with NAT-T.  If/when I fail with 
StrongSwan I'll go the OpenVPN route. (If I don't shoot myself in the head in 
the parking lot first)

Bill S.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

>  Original Message 
> Subject: Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)
> Local Time: December 24, 2017 3:03 PM
> UTC Time: December 24, 2017 11:03 PM
> From: teas...@shorewall.net
> To: shorewall-users@lists.sourceforge.net
>
> On 12/24/2017 02:56 PM, Tom Eastep wrote:
>
>>> I'm now ready to try and set up the Android app.  I wasn't able to
>>> import a .pem cert, but maybe it'll let me import a .der cert.
>>
>> I successfully imported both the .pem CA cert and the .p12 bundle. The
>> former ended up in User Certificates and the latter in Imported.
>
> Other way around...
>
> CA Cert in Imported
> p12 in User
>
> -Tom

Everything goes well with the commands below, but when I try to import the .p12 
into the SS Android app, it seems to be happy, but no user shows up to choose 
from and no certs are in User nor Imported.

# cd /etc/strongswan/ipsec.d/
# strongswan pki --gen --type rsa --outform pem --size 4096 > private/caKey.pem
Self-sign a CA certificate using the generated key:
# strongswan pki --self --in private/caKey.pem --type rsa --dn "C=US, 
O=Quantum, CN=Quantum CA" --outform pem --ca > certs/caCert.pem
CA is ready to issue end-entity certificates.
For each peer, i.e. for all VPN clients and VPN gateways, generate an individual
Gen private key, and issue a matching certificate using new CA:
# strongswan pki --gen --type rsa --outform pem --size 4096 > 
private/quantumKey.pem
# strongswan pki --pub --in private/quantumKey.pem --type rsa | strongswan pki 
--issue --cacert certs/caCert.pem --cakey private/caKey.pem --san 
quantum-equities.com --dn "C=US, O=Quantum, CN=quantum-equities.com" --outform 
pem > certs/quantumCert.pem
# chmod -R 600 private

# openssl pkcs12 -in certs/quantumCert.pem -inkey private/quantumKey.pem 
-certfile certs/caCert.pem -export -out quantum.p12--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

On 12/24/2017 12:59 PM, Tom Eastep wrote:

> After a bit of a hassle with certs, I got it working.
>
> a) I used the StrongSwan Simple CA
> (https://wiki.strongswan.org/projects/strongswan/wiki/SimpleCA) to
> generate my certs, with a subjectAltName. The subjectAltName of the
> local endpoint is gateway.shorewall.net. On the Android, that must be
> placed in the Server Identity setting (Advanced Settings). I imported by
> CA cert separately (shows up under 'Imported' on the Android).
>
> b) Local Endpoint Configuration:
>
> conn %default
> ikelifetime=60m
> keylife=20m
> rekeymargin=3m
> keyingtries=3
> keyexchange=ikev2
> authby=pubkey
>
> conn ipv4
> left=70.90.191.121
> leftid=gateway.shorewall.net
>
> leftsubnet=172.20.1.0/24,172.20.2.0/24,70.90.191.122/31,70.90.191.124/31
> leftcert=gatewayCert.der
> right=%any
> rightsourceip=172.20.3.0/24
> rightdns=172.20.1.253
> auto=add
>
> c) Android configuration:
>
> Server: 70.90.191.121
> VPN Type: IKEv2 Certificate
> User certificate: (CN=phone,O=Shorewall,C=US)
> Ca certificate: Imported CA cert
> Profile name: Shorewall IPv4
> Server Identity: gateway.shorewall.net
>
> -Tom

I'll be darned, it can actually work.  Thank you Tom.

I'm following the same track, and have now gone to the absurd lengths to 
manually gen certs.  It all distills down to these simple commands:
# cd /etc/strongswan/ipsec.d
# strongswan pki --gen --size 4096 > private/caKey.der
Self-sign a CA certificate using the generated key:
# strongswan pki --self --in private/caKey.der --dn "C=US, O=Quantum, 
CN=Quantum CA" --ca > certs/caCert.der
CA is ready to issue end-entity certificates.
For each peer, i.e. for all VPN clients and VPN gateways, generate an individual
Gen private key, and issue a matching certificate using new CA:
# strongswan pki --gen --size 4096 > private/quantumKey.der
# strongswan pki --pub --in private/quantumKey.der | strongswan pki --issue 
--cacert certs/caCert.der --cakey private/caKey.der --san quantum-equities.com 
--dn "C=US, O=Quantum, CN=quantum-equities.com" > certs/quantumCert.der

I'm now ready to try and set up the Android app.  I wasn't able to import a 
.pem cert, but maybe it'll let me import a .der cert.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

> I saw something similar when I neglected to add a subjectAltName
> (gateway.shorewall.net) to the local endpoint's cert.
>
> FWIW, I've attached a log extract of a successful SA establishment.
>
> -Tom

Hm, interesting.  I've consistently used scripts from SomeRandomDude on The 
Internets, and indeed it does not provide for subjectAltName.  Good lead, 
thanks, I'll look for SS's procedure for generating certs.  There is just a 
quagmire haystack of disorganized info out there about this, which I'll bet 
quietly defeats 90% of those who try this.

Setting rightsourceip=192.168.11.0/24and restarting SS didn't change anything.

I've never understood the interplay of IP ranges and addresses between left and 
right, as in some cases 'left' always means 'me', whether setting in local or 
remote, and in other cases it means as I'd understood it, 'left' is ipsec 
gateway and 'right' is remote laptop.

Also I notice that everyone always references the -server- cert and key in 
ipsec.conf settings, whereas the StrongSwan Android app will only accept a .p12 
file.  A .p12 file is genned by the RandomDude's scripts for -user- (as well as 
cert and key), and it also gens the -server- cert and key.  So I can only set 
the -user- cert (.p12) in the Android app.

I'll investigate further.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

> IPSEC configuration issue. I previously posted Strongswan config files
> for my working DNAT setup.
>
> -Tom

True, and I'm basing my endpoint (IPSEC gateway) config on that:

conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=3
keyexchange=ikev2

conn ipv4
left=192.168.111.16
leftid=quantum-equities.com
leftsubnet=192.168.111.0/24,10.1.1.0/24
leftcert=carl-ipseccert.pem
leftid=@quantum-equities.com

right=%any
rightsourceip=192.168.111.0/24
rightdns=192.168.111.10
auto=add

The StrongSwan app doesn't allow much flexibility in what can be set, so I 
think that's right:
Server: quantum-equities.com
VPN Type: IKEv2 Certificate
User Cert: carl-ipsec's VPN cert
User ID: c.a.c...@quantum-equities.com
CA Cert: Select automatically
Profile Name: quantum-equities.com
... no Advanced Settings.

The error has only changed once, when I added hosts and tunnels, and that 
change was only the source daemon. (went from strongswan to charon)  I'm 
putting my ipsec.conf file in /etc/strongswan/ipsec.d which should be picked up 
by the daemon, and seems to be from systemctl status strongswan.

● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
   Loaded: loaded (/usr/lib/systemd/system/strongswan.service; enabled; vendor 
preset: disabled)
   Active: active (running) since Sun 2017-12-24 11:09:50 PST; 3s ago
Main PID: 47590 (starter)
   CGroup: /system.slice/strongswan.service
   ├─47590 /usr/libexec/strongswan/starter --daemon charon --nofork
   └─47599 /usr/libexec/strongswan/charon

Dec 24 11:09:50 zeta.darkmatter.org charon[47599]: 00[CFG] loading aa 
certificates from '/etc/strongswan/ipsec.d/aacerts'
Dec 24 11:09:50 zeta.darkmatter.org charon[47599]: 00[CFG] loading ocsp signer 
certificates from '/etc/strongswan/ipsec.d/ocspcerts'
Dec 24 11:09:50 zeta.darkmatter.org charon[47599]: 00[CFG] loading attribute 
certificates from '/etc/strongswan/ipsec.d/acerts'
Dec 24 11:09:50 zeta.darkmatter.org charon[47599]: 00[CFG] loading crls from 
'/etc/strongswan/ipsec.d/crls'
Dec 24 11:09:50 zeta.darkmatter.org charon[47599]: 00[CFG] loading secrets from 
'/etc/strongswan/ipsec.secrets'
Dec 24 11:09:50 zeta.darkmatter.org charon[47599]: 00[CFG]   loaded RSA private 
key from '/etc/strongswan/ipsec.d/private/carl-ipseckey.pem'
Dec 24 11:09:50 zeta.darkmatter.org charon[47599]: 00[LIB] loaded plugins: 
charon random nonce aes sha1 sha2 pem pkcs1 gmp x509 curl revocation hmac 
stroke kernel-netlink socket-default updown
Dec 24 11:09:50 zeta.darkmatter.org charon[47599]: 00[JOB] spawning 16 worker 
threads
Dec 24 11:09:50 zeta.darkmatter.org ipsec_starter[47590]: charon (47599) 
started after 20 ms
Dec 24 11:09:50 zeta.darkmatter.org strongswan[47590]: charon (47599) started 
after 20 ms

For some reason the endpoint sees me trying to authenticate from 172.58.40.177 
rather than from at 29.124.236.116, my phone's actual IP.

I must be consistently doing something fundamentally wrong, which few other 
people out there have done, judging from searches.  Two weeks full-time, trying 
to learn and fix this, and I am out of ideas.  It seems hopeless.

Dec 24 11:15:17 zeta charon: 05[NET] received packet: from 172.58.40.177[23037] 
to 192.168.111.16[500] (704 bytes)
Dec 24 11:15:17 zeta charon: 05[ENC] parsed IKE_SA_INIT request 0 [ SA KE No 
N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Dec 24 11:15:17 zeta charon: 05[IKE] no IKE config found for 
192.168.111.16...172.58.40.177, sending NO_PROPOSAL_CHOSEN
Dec 24 11:15:17 zeta charon: 05[ENC] generating IKE_SA_INIT response 0 [ 
N(NO_PROP) ]
Dec 24 11:15:17 zeta charon: 05[NET] sending packet: from 192.168.111.16[500] 
to 172.58.40.177[23037] (36 bytes)--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

> I would think you would want:
> interfaces:
> -eth0routefilter=0,logmartians=1
> hosts:
> vpn   eth0:172.58.43.0/24
> neteth0:0.0.0.0/0
>
> I'm assuming 172.58.43.0/24 is a private subnet (RFC1918).
>
> Bill

  172. is from my phone on a national carrier, and could be anything depending 
on where I am.  I don't have anything in hosts.

Tom's right, I should have included the standard details;  I was so distressed 
at the time I didn't think of it.  For two weeks I have been unable to make the 
StrongSwan Android app connect to my very first VPN, StrongSwan on CentOS.  
There were no Shorewall messages and I was getting despondent.  Then I tried 
the phone's 'add a VPN' function (instead of the SS app) and I got these noted 
blockages!  I am not notified of Shorewall blockages and I don't understand why.

The Shorewall support docs says I must have ipsec-tools installed, and I did 
not.  Its raccoon daemon is specifically for ikev1 and I'm only running v2, but 
there may be some other function it provides.  It's not called as a dependency 
of CentOS package StrongSwan though, which I don't understand.  When I 
installed ipsec-tools and restarted the SS daemon, it didn't change things;  
500 is still blocked.

Internet is otherwise working on this machine.  I've forwarded the 
shorewall_dump to Tom.

I'm trying to connect from my phone at 29.124.236.116 to my router (KVM VM 
running CentOS) at 50.35.109.212,  NATted through router 192.168.111.1 to the 
IPSec gateway at 192.168.111.16.  The errors and dump are from this last 
gateway machine.  I don't know what 172.58.43.* has to do with anything.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] UDP Getting Blocked When Unblocked (StrongSwan)

[Colony.three via Shorewall-users]

I don't understand this:

[184624.505739] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=85.6.183.101 
DST=192.168.111.16 LEN=408 TOS=0x00 PREC=0x00 TTL=115 ID=10959 PROTO=UDP 
SPT=1024 DPT=500 LEN=388
[184627.506014] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=85.6.183.101 
DST=192.168.111.16 LEN=408 TOS=0x00 PREC=0x00 TTL=115 ID=10960 PROTO=UDP 
SPT=1024 DPT=500 LEN=388
[184630.506281] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=85.6.183.101 
DST=192.168.111.16 LEN=408 TOS=0x00 PREC=0x00 TTL=115 ID=10961 PROTO=UDP 
SPT=1024 DPT=500 LEN=388
[184633.506518] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=85.6.183.101 
DST=192.168.111.16 LEN=408 TOS=0x00 PREC=0x00 TTL=115 ID=10962 PROTO=UDP 
SPT=1024 DPT=500 LEN=388
[184636.506136] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=85.6.183.101 
DST=192.168.111.16 LEN=408 TOS=0x00 PREC=0x00 TTL=115 ID=10963 PROTO=UDP 
SPT=1024 DPT=500 LEN=388
[184639.506758] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=85.6.183.101 
DST=192.168.111.16 LEN=408 TOS=0x00 PREC=0x00 TTL=115 ID=10964 PROTO=UDP 
SPT=1024 DPT=500 LEN=388
[184642.505948] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=85.6.183.101 
DST=192.168.111.16 LEN=408 TOS=0x00 PREC=0x00 TTL=115 ID=10965 PROTO=UDP 
SPT=1024 DPT=500 LEN=388
[189767.312541] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=172.58.43.44 
DST=192.168.111.16 LEN=732 TOS=0x00 PREC=0x00 TTL=54 ID=46913 DF PROTO=UDP 
SPT=65138 DPT=500 LEN=712
[189769.362835] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=172.58.43.44 
DST=192.168.111.16 LEN=732 TOS=0x00 PREC=0x00 TTL=54 ID=46914 DF PROTO=UDP 
SPT=65138 DPT=500 LEN=712
[189772.174498] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=172.58.43.44 
DST=192.168.111.16 LEN=732 TOS=0x00 PREC=0x00 TTL=54 ID=46915 DF PROTO=UDP 
SPT=65138 DPT=500 LEN=712
[189776.045296] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=172.58.43.44 
DST=192.168.111.16 LEN=732 TOS=0x00 PREC=0x00 TTL=54 ID=46916 DF PROTO=UDP 
SPT=65138 DPT=500 LEN=712
[189781.611542] Shorewall:net-fw:DROP:IN=eth0 OUT= 
MAC=52:54:00:c0:93:30:52:54:00:d7:db:bb:08:00 SRC=172.58.43.44 
DST=192.168.111.16 LEN=732 TOS=0x00 PREC=0x00 TTL=54 ID=46917 DF PROTO=UDP 
SPT=65138 DPT=500 LEN=712

... when policy has:
$FW all REJECT  info(uid)
net all DROPinfo(uid)
vpn all DROPinfo(uid)
#local  all REJECT  info(uid)
all all REJECT  info(uid)

... and rules has:
# VPN
ACCEPT  vpn $FW udp 500,ipsec-nat-t -
ACCEPT  net $FW udp 500,ipsec-nat-t -

In interfaces I only have:
-   lo  ignore
net eth0 tcpflags,nosmurfs,sourceroute=0

... with no vpn.  Could this be the problem?

And I don't understand why it is that in rules when I specify the port as 
isakmp (rather than 500), it gets blocked?  Same reason, whatever it is?--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Centos7: SELinux is preventing /usr/bin/touch from 'write' accesses on the file shorewall

[Colony.three via Shorewall-users]

>  Original Message 
> Subject: Re: [Shorewall-users] Centos7: SELinux is preventing /usr/bin/touch 
> from 'write' accesses on the file shorewall
> Local Time: December 17, 2017 1:58 PM
> UTC Time: December 17, 2017 9:58 PM
> From: d.le...@solinos.it
> To: shorewall-users@lists.sourceforge.net
>
> Il giorno dom, 17/12/2017 alle 13.10 -0500, Colony.three via Shorewall-
> users ha scritto:
>
>> It's not clear what you're doing here. In several cases you have the
>> output of ls -Z, without entering the command?
>>
>> Now this is the output of ls -Z
>>
>> [ root@s-virt ~]# ls -lZ /run/lock/subsys/*
>> -rw-r--r--. root root system_u:object_r:var_lock_t:s0 
>> /run/lock/subsys/libvirt-guests
>> -rw-r--r--. root root system_u:object_r:var_lock_t:s0 
>> /run/lock/subsys/network
>> -rw---. root root unconfined_u:object_r:var_lock_t:s0 
>> /run/lock/subsys/shorewall
>>
>> Yes selinux is prohibiting from looking at {getattr}, creating
>> {write}, or deleting {unlink} the shorewall lockfile. The correct
>> setting for the lockfile (and the path down to it) is:
>> system_u:object_r:var_lock_t:s0
>>
>> The file has not this attribute.
>> And if I change it
>>
>> [ root@s-virt ~]# chcon system_u:object_r:var_lock_t:s0 
>> /run/lock/subsys/shorewall
>>
>> It come back after a while.
>>
>> You don't say whether you've rebooted or not.
>>
>> No I do not have reboot, I do not know whats happen if I reboot.
>>
>> I have only restart the shorewall service and some time, when I do
>> that, I get 4 Selinux error into log.
>>
>> I just want to point out that sometimes in the logs I detect these
>> selinux errors
>>
>> [ root@s-virt ~]# grep -E 'denied.*shorewall' /var/log/audit/audit.log|tail 
>> -4
>> type=AVC msg=audit(1513547387.366:1560): avc: denied { getattr } for 
>> pid=17154 comm="rm" path="/run/lock/subsys/shorewall" dev="tmpfs" ino=56603 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=system_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513547387.366:1561): avc: denied { unlink } for 
>> pid=17154 comm="rm" name="shorewall" dev="tmpfs" ino=56603 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=system_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513547387.758:1605): avc: denied { write } for pid=17405 
>> comm="touch" name="shorewall" dev="tmpfs" ino=56603 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=system_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513547387.758:1606): avc: denied { write } for pid=17405 
>> comm="touch" name="shorewall" dev="tmpfs" ino=56603 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=system_u:object_r:var_lock_t:s0 tclass=file
>>
>> There is a solution that I can apply or i'ts a bug?
>>
>> Thanks

I guess that this is an important server, but you must be able to reboot.

The problem comes back after a bit?  It's doubtful that it's a bug with RHEL.  
I suspect that you've made changes in the system without rebooting.

As to selinux errors, there are several ways to approach them, and lots of ways 
to do it wrong.  And lots of selinux errors are harmless and would take weeks 
of study to change.  The best thing is to start with a baseline by rebooting.  
Be sure that you have good backups.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Centos7: SELinux is preventing /usr/bin/touch from 'write' accesses on the file shorewall

[Colony.three via Shorewall-users]

It's not clear what you're doing here.  In several cases you have the output of 
ls -Z, without entering the command?

Yes selinux is prohibiting from looking at {getattr}, creating {write}, or 
deleting {unlink} the shorewall lockfile.  The correct setting for the lockfile 
(and the path down to it) is:  system_u:object_r:var_lock_t:s0

You don't say whether you've rebooted or not.

>  Original Message 
> Subject: Re: [Shorewall-users] Centos7: SELinux is preventing /usr/bin/touch 
> from 'write' accesses on the file shorewall
> Local Time: December 17, 2017 9:12 AM
> UTC Time: December 17, 2017 5:12 PM
> From: d.le...@solinos.it
> To: shorewall-users@lists.sourceforge.net
>
> Il giorno ven, 15/12/2017 alle 10.10 -0500, Bill Shirley ha scritto:
>
>> He should at least do a 'ls -lZ' on the file and report to the list.
>>
>> I have activate this log:
>>
>> [ root@s-virt ~]# tail -f /var/log/audit/audit.log | grep --color=auto 
>> denied &
>> [1] 7937
>>
>> This is the result:
>>
>> [ root@s-virt ~]# ls -lZ /run/lock/subsys/shorewall /run/lock/subsys/
>> -rw---. root root unconfined_u:object_r:var_lock_t:s0 
>> /run/lock/subsys/shorewall
>>
>> /run/lock/subsys/:
>> -rw-r--r--. root root system_u:object_r:var_lock_t:s0 libvirt-guests
>> -rw-r--r--. root root system_u:object_r:var_lock_t:s0 network
>> -rw---. root root unconfined_u:object_r:var_lock_t:s0 shorewall
>> [ root@s-virt ~]# chcon system_u:object_r:var_lock_t:s0 
>> /run/lock/subsys/shorewall
>> [ root@s-virt ~]# service shorewall restart
>> Redirecting to /bin/systemctl restart shorewall.service
>> type=AVC msg=audit(1513528726.972:629): avc: denied { getattr } for pid=6475 
>> comm="rm" path="/run/lock/subsys/shorewall" dev="tmpfs" ino=40257 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=system_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513528726.972:630): avc: denied { unlink } for pid=6475 
>> comm="rm" name="shorewall" dev="tmpfs" ino=40257 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=system_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513528727.363:674): avc: denied { write } for pid=6724 
>> comm="touch" name="shorewall" dev="tmpfs" ino=40257 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=system_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513528727.363:675): avc: denied { write } for pid=6724 
>> comm="touch" name="shorewall" dev="tmpfs" ino=40257 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=system_u:object_r:var_lock_t:s0 tclass=file
>> [ root@s-virt ~]# ls -lZ /run/lock/subsys/shorewall
>> -rw---. root root system_u:object_r:var_lock_t:s0 
>> /run/lock/subsys/shorewall
>> [ root@s-virt ~]# chcon system_u:system_r:shorewall_t:s0 
>> /run/lock/subsys/shorewall
>> type=AVC msg=audit(1513528816.785:684): avc: denied { relabelto } for 
>> pid=6791 comm="chcon" name="shorewall" dev="tmpfs" ino=40257 
>> scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
>> tcontext=system_u:system_r:shorewall_t:s0 tclass=file
>> chcon: cambio del contesto di "/run/lock/subsys/shorewall" in 
>> "system_u:system_r:shorewall_t:s0" non riuscito: Permesso negato
>>
>> Also a 'grep denied /var/log/audit/audit.log'.
>>
>> This is output of selinux error
>>
>> [ root@s-virt ~]# grep -E 'denied.*shorewall' /var/log/audit/audit.log|tail 
>> -16
>> type=AVC msg=audit(1513182259.328:11708): avc: denied { getattr } for 
>> pid=25598 comm="rm" path="/run/lock/subsys/shorewall" dev="tmpfs" ino=192726 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=unconfined_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513182259.328:11709): avc: denied { unlink } for 
>> pid=25598 comm="rm" name="shorewall" dev="tmpfs" ino=192726 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=unconfined_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513182259.738:11753): avc: denied { write } for 
>> pid=25858 comm="touch" name="shorewall" dev="tmpfs" ino=192726 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=unconfined_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513182259.738:11754): avc: denied { write } for 
>> pid=25858 comm="touch" name="shorewall" dev="tmpfs" ino=192726 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=unconfined_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513183584.000:11776): avc: denied { getattr } for 
>> pid=26688 comm="rm" path="/run/lock/subsys/shorewall" dev="tmpfs" ino=192726 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=unconfined_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513183584.000:11777): avc: denied { unlink } for 
>> pid=26688 comm="rm" name="shorewall" dev="tmpfs" ino=192726 
>> scontext=system_u:system_r:shorewall_t:s0 
>> tcontext=unconfined_u:object_r:var_lock_t:s0 tclass=file
>> type=AVC msg=audit(1513183584.415:11821): avc: denied { write } for 
>> pid=26941 comm="touch" name="shorewall" 

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

>> DNAT { SOURCE=net, DEST=apps:172.20.2.44, PROTO=udp,
>> DPORT=500,4500, ORIGDEST=$IPSEC_IP }
>
> Tom, on this line, is IPSEC_IP something I must set?
>
> If so, would this be the router's outside IP?  Could I do a command 
> substitution like $(curl ipinfo.io/ip) ?

PS - Here's what I've cooked up for the ipsec.d/ipsec-local.conf files.  No 
idea if they work, but hopefully will today:

Laptop:

# Debug: A  comma  separated list, e.g: dmn 3, ike 1, net -1.
# Acceptable values for types are dmn, mgr, ike, chd,  job,  cfg, knl,
#   net,  asn, enc, lib, esp, tls, tnc, imc, imv, pts
#   and the level is one of -1, 0, 1, 2, 3, 4
#charondebug = 
#charondebug="cfg 2, dmn 2, ike 2, net 2"

conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyexchange=ikev2
# https://lists.strongswan.org/pipermail/users/2015-April/007809.html
ike=aes128gcm16-prfsha256-ntru256,aes256gcm16-prfsha384-ntru384!
esp=aes128gcm16-ntru256,aes256gcm16-ntru384!
dpdaction=restart

conn vpn
left=%any
leftcert=quantumcert.pem
leftsourceip=%config

right=192.168.1.2
rightsubnet=192.168.1.0/24,10.0.0.0/24

auto=start

Left ipsec gateway (in LAN, beyond the router)

# Debug: A  comma  separated list, e.g: dmn 3, ike 1, net -1.
# Acceptable values for types are dmn, mgr, ike, chd,  job,  cfg, knl,
#   net,  asn, enc, lib, esp, tls, tnc, imc, imv, pts
#   and the level is one of -1, 0, 1, 2, 3, 4
#charondebug = 
#charondebug="cfg 2, dmn 2, ike 2, net 2"

conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyexchange=ikev2
# https://lists.strongswan.org/pipermail/users/2015-April/007809.html
ike=aes128gcm16-prfsha256-ntru256,aes256gcm16-prfsha384-ntru384!
esp=aes128gcm16-ntru256,aes256gcm16-ntru384!
dpdaction=clear

conn vpn
left=192.168.1.13
leftcert=quantumcert.pem
leftsendcert=always
leftsubnet=192.168.1.0/24,10.0.0.0/24

right=%any
rightsourceip=192.168.1.2/32
rightdns=192.168.1.1

auto=add--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

> DNAT { SOURCE=net, DEST=apps:172.20.2.44, PROTO=udp,
> DPORT=500,4500, ORIGDEST=$IPSEC_IP }

Tom, on this line, is IPSEC_IP something I must set?

If so, would this be the router's outside IP?  Could I do a command 
substitution like $(curl ipinfo.io/ip) ?--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

I did not mention IPSEC SAs. The problem with trying to access the rest

> of the LAN is that response packets from other LAN systems aren't routed
> back through the IPEC endpoint. As I mentioned, you can force that to
> happen by using SNAT on the endpoint host, if you are willing to accept
> that traffic from the remote laptop appears to originate on the endpoint
> host.
>
> Here are StrongSwan configuration files that I've tested to my laptop to
> access my LAN using the SNAT kludge. The endpoint is in the zone called
> 'apps' and has local IP 172.20.2.44.
>
> Warning -- my mailer has folded the long '*subnet' lines.
>
> Laptop ipsec.conf:
>
> conn %default
> ikelifetime=60m
> keylife=20m
> rekeymargin=3m
> keyingtries=3
> keyexchange=ikev2
> authby=pubkey
> dpdaction=restart
>
> conn vpn4
> left=%any
> leftcert=debianvmCert.der
> leftid=debianvm.shorewall.net
> leftsourceip=%config
> right=172.20.2.44
> rightid=irssi.shorewall.net
>
> rightsubnet=172.20.1.0/24,172.20.2.0/24,70.90.191.122/31,70.90.191.124/31
> auto=start
>
> Local Endpoint ipsec.conf:
>
> conn %default
> ikelifetime=60m
> keylife=20m
> rekeymargin=3m
> keyingtries=3
> keyexchange=ikev2
> authby=pubkey
>
> conn ipv4
> left=172.20.2.44
> leftid=irssi.shorewall.net
>
> leftsubnet=172.20.1.0/24,172.20.2.0/24,70.90.191.122/31,70.90.191.124/31
> leftcert=irssiCert.der
> right=%any
> rightsourceip=172.20.3.0/24
> rightdns=172.20.1.253
> auto=add
>
> The following rule is present in /etc/shorewall/rules on the router:
>
> DNAT { SOURCE=net, DEST=apps:172.20.2.44, PROTO=udp,
> DPORT=500,4500, ORIGDEST=$IPSEC_IP }
>
> There are other rules/policies between apps:172.20.2.44 and the other
> local zones.
>
> On the endpoint system, I executed the following command:
>
> iptables -t nat -A POSTROUTING -j MASQUERADE
>
> Warning to readers: I have been unable to get a similar IPv6 config to
> work, but I suspect that has to do with the fact that the local IPSEC
> endpoint is in an LXC container. Packets that have had IPv6 SNAT applied
> can be seen leaving the container's eth0, but are not seen on the
> connected bridge hosted in the router!!??
>
> FWIW, my normal IPSEC local endpoint is on my router; the above configs
> were created just to test my SNAT hypothisis.
>
> -Tom

Wow great resource, thanks Tom.

For now I'd better belay my ikev2 port 500 change, and give the above a try..--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

> I'll look at what you say below Bill.
>
> But keep in mind that the attacks I'm concerned about are typically buffer 
> overflows and other sideband attacks.  Directness rarely succeeds in hacking 
> these days.  There are always unknown vulns.
>
> I'm suspicioning that the reason Tom says that only the router can sponsor 
> the ipsec gateway, is that ports other than 4500 are used, although he 
> doesn't specify.  I know that at least with LibreSwan there is a setting to 
> constrain it to 4500 for this reason.  Not sure about StrongSwan, but I'll 
> look into it today.

Now I remember.  Tom said the reason an incoming remote could not access the 
rest of the LAN is something about IPsec SAs.  I couldn't understand it.

But it may be that his experience is with LibreSwan.  StrongSwan ostensibly 
does have [support for NAT 
traversal](https://wiki.strongswan.org/projects/strongswan/wiki/NatTraversal), 
and I'm trying to understand that now.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] IPSec Tunneling

[Colony.three via Shorewall-users]

I have a VM which is the LAN router, and another VM in the LAN which is the 
ipsec gateway. (strongswan)

I'm not fully understanding the guide here;  
http://www.shorewall.net/IPSEC-2.6.html

- Does this still apply to kernel 4.*?  There isn't a 
[http://www.shorewall.net/IPSEC.html](http://www.shorewall.net/IPSEC-2.6.html)

- It doesn't say to set up DNAT on the router.  How does the router know where 
the ipsec gateway is?

- On the laptop, tunnels should be set as:  ipsec net 206.162.148.9 vpn.  But 
what is that IP?  The dynamic IP of the laptop, or the outside interface of the 
remote router?

- If the latter, is there a way in the laptop's tunnels to, instead of an 
explicit IP, do a DNS request, to get that remote IP?

- Wouldn't I need to set up DNAT in and SNAT out for ports 500 and 4500?

- How do I enable protocols 50 & 51?  Would that be on one or both ports?--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DNAT Not Working

[Colony.three via Shorewall-users]

>> If necessary, can I somehow enter it here as a system variable?

>> You can use 
>>
>> -Tom

Holy cow, this saves all kinds of scripted checks and saves!

Thanks for all your help Tom.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DNAT Not Working

[Colony.three via Shorewall-users]

> On 11/20/2017 09:27 AM, Colony.three via Shorewall-users wrote:
>
>>> Are you sure this isn't working. I can connect to the firewall's
>>> external IP on port 80 and I get the Quantum Equities web site.
>>>
>>> -Tom
>>>
>>> ___
>>
>> Hm, that's odd.  My remote OpenStack instance is CentOS Minimal so no
>> GUI.  I have to use curl to test, and it times out.  nc also times out.
>> This is from a VM at Internap, which I ssh in to from my LAN.  No dmesg
>> errors anywhere.  The shorewall counter increments to 2 immediately on
>> clear, but never increments on curl nor nc from Internap.
>>
>> Well -- I can browse quantum-equities.com from my local LAN just fine.
>> And from inside my LAN I can't pull up quantum-equities.com. (LAN
>> laptop==>routerSNAT==>internet/50.35.109.212
>> http://50.35.109.212==>routerNATxxx)
>> You mention several times in the docs that accessing it from inside
>> doesn't work, but I don't understand the dynamics.  I should be able to
>> pull up this domain name from inside the LAN through the router's
>> external interface, as a regular website shouldn't I?
>>
>> From inside the LAN connected to the Shorewall system, you must also use
>> DNAT if you want to access DMZ servers via the firewall external IP:
>>
>> DNAT loc dmz tcp 80 - 50.35.109.212
>>
>> or
>>
>> Web(DNAT) loc dmz - - - 50.35.109.212
>>
>> The latter also DNATs port 443 which apparently isn't being used on the
>> Quantum website.
>>
>> -Tom

By the mighty Hammer Of Thor, it works.  I don't understand why my remote curl 
or nc attempts didn't work.

When using:  Web(DNAT)loc   dmz   - - -   50.35.109.212
... is that last 50.35.109.212 necessary? (It may change periodically)  If 
necessary, can I somehow enter it here as a system variable?

I haven't been able to get SSL running as certbot (LetsEncrypt) couldn't verify 
my domain.  But now it should be able to.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DNAT Not Working

[Colony.three via Shorewall-users]

> Are you sure this isn't working. I can connect to the firewall's
> external IP on port 80 and I get the Quantum Equities web site.
>
> -Tom
>
> ___

Hm, that's odd.  My remote OpenStack instance is CentOS Minimal so no GUI.  I 
have to use curl to test, and it times out.  nc also times out.  This is from a 
VM at Internap, which I ssh in to from my LAN.  No dmesg errors anywhere.  The 
shorewall counter increments to 2 immediately on clear, but never increments on 
curl nor nc from Internap.

And from inside my LAN I can't pull up quantum-equities.com. (LAN 
laptop==>routerSNAT==>internet/50.35.109.212==>routerNATxxx)

You mention several times in the docs that accessing it from inside doesn't 
work, but I don't understand the dynamics.  I should be able to pull up this 
domain name from inside the LAN through the router's external interface, as a 
regular website shouldn't I?

If I can't, this implies that email won't work either.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DNAT Not Working

[Colony.three via Shorewall-users]

I've set ACCEPT rules for net to $FW and net to dmz (not sure which applies) 
for http and https.

Going through the FAQ here:  http://shorewall.net/FAQ.htm#faq1a
- I'm testing from a remote OpenStack VM (Internap) using:
# curl -v http://50.35.109.212
* About to connect() to 50.35.109.212 port 80 (#0)
*   Trying 50.35.109.212...
* Connection timed out
* Failed connect to 50.35.109.212:80; Connection timed out
* Closing connection 0
curl: (7) Failed connect to 50.35.109.212:80; Connection timed out

- The gateway on the dmz server is set to 10.15.15.2, which is the dmz inside 
interface on the router.  And it can access The Internets fine using SNAT.
- I've previously confirmed that 80 can reach through my ISP.
- Running CentOS7.4.

http://shorewall.net/FAQ.htm#faq1b
(On router)
# shorewall reset
Shorewall Counters Reset
# shorewall show nat
pkts bytes target prot opt in out source   destination
2   128 DNAT   tcp  --  *  *   0.0.0.0/00.0.0.0/0   
 multipo
... note: instantly there is a count of 2 when I haven't done anything.
(On router)
# shorewall reset
# shorewall show nat
   2   128 DNAT   tcp  --  *  *   0.0.0.0/00.0.0.0/0
multiport dports 80,443 to:10.1.1.30
(On remote)
# curl -v http://50.35.109.212
(On router)
# shorewall show nat
   2   128 DNAT   tcp  --  *  *   0.0.0.0/00.0.0.0/0
multiport dports 80,443 to:10.1.1.30
... note count remains 2.

- I'd previously set my SSHd server on the router to listen on 80, 443, 587, 
etc, and I could always SSH in to the router from the remote machine.  So those 
ports aren't blocked, unless it's a protocol-sensitive block.
-  I can not understand this second possibility:  "you are trying to connect to 
a secondary IP address on your firewall and your rule is only redirecting the 
primary IP address (You need to specify the secondary IP address in the “ORIG. 
DEST.” column in your DNAT rule); or"
- (On router - 50.35.109.212)
# tcpdump |grep 72.251.232.105
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
(On remote machine - 72.251.232.105)
# curl -v http://50.35.109.212
(On router, zip, even after curl times out.

- And the last possibility (On router):
# ifconfig
eth0: flags=4163  mtu 1500
inet 50.35.109.212  netmask 255.255.240.0  broadcast 50.35.111.255

I can't see what is wrong.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] DNAT Not Working

[Colony.three via Shorewall-users]

> Do you have firewall rules to allow that traffic through?  Pretty much every 
> time
> I  can’t get something like this to work it turns out to be because it’s 
> blocked by
> the firewall.

>   -Les

Sure.  That's the purpose of the NAT command isn't it?

Anyway, there are no error messages in dmesg whatsoever related to the source 
IP.  It should log them if it's blocking something, right?  policy is set to:
local   all REJECT  info(uid,tcp_options)
net all DROPinfo(uid,tcp_options)
dmz all DROPinfo(uid,tcp_options)
all all REJECT  info(uid,tcp_options)

If not, this is the reason I said earlier that half the time Shorewall blocks 
but doesn't log messages.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] DNAT Not Working

[Colony.three via Shorewall-users]

Hello, I can not get DNAT to work to save my life.

All machines are CentOS7 KVM virtual machines, one the internet-connected 
router, and the other in the DMZ.

I've gone through the docs and there seem to be two methods of port-forwarding, 
and neither works in the router:
DNAT   net dmz:10.1.1.30 tcp http,https
... and
Web(DNAT) net   dmz:10.1.1.30
Web(ACCEPT) local dmz:10.1.1.30
(Of course10.1.1.30 is the dmx web server)

I checked both using a remote Openstack VM.  And I'd previously used that OS VM 
to check that port 80, 443, etc could get through my ISP to the 
router/firewall, and they can.  But port-forwarding simply does not work in the 
router.  I even tried the port 5000 mapped to 80 trick and no dice.

I turned off SELinux, and set aside my sysctl.conf security file, and no 
better.  I can reach the webserver in the dmz from the local LAN, so the 
problem must be in port forwarding.  There are no error messages in dmesg.

I've forwarded the dump to Tom.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Setting Up a DMZ Fail

[Colony.three via Shorewall-users]

>  Original Message 
> Subject: Re: [Shorewall-users] Setting Up a DMZ Fail
> Local Time: November 13, 2017 4:37 PM
> UTC Time: November 14, 2017 12:37 AM
> From: teas...@shorewall.net
> To: shorewall-users@lists.sourceforge.net
>
> On 11/13/2017 03:25 PM, Colony.three via Shorewall-users wrote:
>
>>> I've given up on trying to set up a Private Virtual Network in
>>> virt-manager (KVM), as it does not work.  (CentOS7.4 all 'round)
>>> So I've now assigned a hardware ethernet port to the DMZ VM and one to
>>> the router VM, just like all the other VMs.  The DMZ and router have
>>> their own IP class C's (different from the LAN).  I'm uneasy with
>>> this, as if an interface could be put in promiscuous...
>>> But what else am I going to do?  Using a bridge isn't very secure as
>>> it depends on a software driver, and if a flaw is found/exists in
>>> that?  It is hard to get bolt-sure isolation from some VMs, with
>>> communication in others.
>>> With hardware interfaces and SNAT MASQUERADE defined for the LAN IP
>>> and DMZ IP, the LAN can get out to the WAN -- but not the DMZ
>>> machine.  Nothing in the logs, as usual.
>>
>> Presuming that my LAN has to be NATted to the DMZ in the router to SSH
>> into it, I added in snat:
>>
>> Your LAN does NOT have to be NATted to your DMZ.
>>
>> SNAT(10.1.111.3) 192.168.1.2   10.1.111.2ssh
>> Not understanding what to put in () (and it doesn't work without
>> something) I put in an IP that's in the same class C as the DMZ, which
>> otherwise isn't being used.  192.168.1.2 is the source IP in the LAN and
>> 10.1.111.2 is the DMZ interface in the router which is supposed to point
>> to the DMZ machine at 10.1.111.30.
>> But now Shorewall won't start because it does not recognize the service
>> ssh!  WTH?  I knew it's good but just to be sure I checked
>> /etc/services, and yep, port 22.
>>
>> You are missing the protocol column. Also, the syntax of the destination
>> column requires an interface name.
>> Even if this worked, another problem with this is that if I snat all SSH
>> traffic to the DMZ, I can no longer SSH out to The Internets.
>> Everything gets turned around to the DMZ.
>> I can't believe there isn't a writeup on this anywhere.
>
> What is different about your configuration and the one shown in the
> Three Interface Howto (http://www.shorewall.org/
> three-interface.htm)?
>
> -Tom

The problem was with my DMZ VM.  I found I couldn't get out of it to do 
anything, and nobody could get in.  Only had access through the KVM console.  
I'm so exhausted that I don't remember what was wrong, but all is working now 
and I've taken backups of this clean snapshot on which I can base experiments.

Still left with the question of the most secure way to join the DMZ to the 
network.  Right now I'm using hardware SR-IOV interfaces, but they could be put 
in promiscuous mode.  KVM's Private Virtual Netwoking didn't work, and the 
software bridge driver in the host could have exploitable flaws.

Wondering what best practice is for KVM DMZ isolation?  (And I'm probably not 
the only one here)--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Setting Up a DMZ Fail

[Colony.three via Shorewall-users]

> I've given up on trying to set up a Private Virtual Network in virt-manager 
> (KVM), as it does not work.  (CentOS7.4 all 'round)
>
> So I've now assigned a hardware ethernet port to the DMZ VM and one to the 
> router VM, just like all the other VMs.  The DMZ and router have their own IP 
> class C's (different from the LAN).  I'm uneasy with this, as if an interface 
> could be put in promiscuous...
>
> But what else am I going to do?  Using a bridge isn't very secure as it 
> depends on a software driver, and if a flaw is found/exists in that?  It is 
> hard to get bolt-sure isolation from some VMs, with communication in others.
>
> With hardware interfaces and SNAT MASQUERADE defined for the LAN IP and DMZ 
> IP, the LAN can get out to the WAN -- but not the DMZ machine.  Nothing in 
> the logs, as usual.

Presuming that my LAN has to be NATted to the DMZ in the router to SSH into it, 
I added in snat:
SNAT(10.1.111.3) 192.168.1.2   10.1.111.2ssh

Not understanding what to put in () (and it doesn't work without something) I 
put in an IP that's in the same class C as the DMZ, which otherwise isn't being 
used.  192.168.1.2 is the source IP in the LAN and 10.1.111.2 is the DMZ 
interface in the router which is supposed to point to the DMZ machine at 
10.1.111.30.

But now Shorewall won't start because it does not recognize the service ssh!  
WTH?  I knew it's good but just to be sure I checked /etc/services, and yep, 
port 22.

Even if this worked, another problem with this is that if I snat all SSH 
traffic to the DMZ, I can no longer SSH out to The Internets.  Everything gets 
turned around to the DMZ.

I can't believe there isn't a writeup on this anywhere.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Setting Up a DMZ Fail

[Colony.three via Shorewall-users]

I've given up on trying to set up a Private Virtual Network in virt-manager 
(KVM), as it does not work.  (CentOS7.4 all 'round)

So I've now assigned a hardware ethernet port to the DMZ VM and one to the 
router VM, just like all the other VMs.  The DMZ and router have their own IP 
class C's (different from the LAN).  I'm uneasy with this, as if an interface 
could be put in promiscuous...

But what else am I going to do?  Using a bridge isn't very secure as it depends 
on a software driver, and if a flaw is found/exists in that?  It is hard to get 
bolt-sure isolation from some VMs, with communication in others.

With hardware interfaces and SNAT MASQUERADE defined for the LAN IP and DMZ IP, 
the LAN can get out to the WAN -- but not the DMZ machine.  Nothing in the 
logs, as usual.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Setting Up a DMZ Fail

[Colony.three via Shorewall-users]

> We need to see the output of 'shorewall dump'. Please forward it as a
> compressed attachment; you can send it to me privately if you like.
>
> -Tom

It's a problem for me to get emails to you Tom, or I would have sent it.  Spam 
protections have eclipsed my one-horse hosting service (which has all but 
collapsed), and this is all about my trying to move to my own cloud instance.

Last time, you gave me two additional addresses to try, but one bounced, and I 
never heard back from you on the other so don't know whether it went through.

I'm about ready to hand-deliver a printout to you...  (I'm in Edmonds)--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Setting Up a DMZ Fail

[Colony.three via Shorewall-users]

> Typical setup.  All systems running CentOS7.4 on KVM.  Shorewall 5.0.14.1.  
> Communication with DMZ by a virtual private bridge built in virt-manager, and 
> communication between LAN machines is by SRIOT ethernet hardware.
>
> The router is a VM with 3 interfaces -- fiberoptic, LAN, DMZ. -- and I 
> followed the doc for 3 interface, setting the SNAT file:
> .MASQUERADE  10.1.111.30/32,192.168.1.0/24   eth1
> (DMZ: 10.  LAN: 192.)
>
> LAN masquerades through the router fine.  From the router I can ping the dmz 
> and ssh to it just fine.
>
> Problem is the dmz machine can't ping out;  can't even get nameservice.  And 
> dmesg in both the dmz and router show -nothing- in dmesg.
>
> Also I can't ssh from the lan to the dmz machine.  I can ping it from the 
> router, and ssh in, but not from the LAN.

Here's the routing table on the router:

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
default 50-105-82-1.hll 0.0.0.0 UG0  00 eth1
10.1.111.00.0.0.0 255.255.255.0   U 0  00 eth0
50.105.82.0 0.0.0.0 255.255.240.0   U 0  00 eth1
link-local  0.0.0.0 255.255.0.0 U 1002   00 ens10
link-local  0.0.0.0 255.255.0.0 U 1003   00 eth1
link-local  0.0.0.0 255.255.0.0 U 1004   00 eth0
192.168.1.0   0.0.0.0 255.255.255.0   U 0  00 ens10

I can see why the LAN and DMZ should masquerade through the router to the world 
(although the DMZ does not).  But how would I wire it so I can ssh from the LAN 
to the DMZ?  Seems like SSH should go from the LAN into the router, and then 
out the DMZ because that's where its destination address is.  So no 
masquerading should be necessary?  Unfortunately it is not, and there's nothing 
in the logs.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Setting Up a DMZ Fail

[Colony.three via Shorewall-users]

Typical setup.  All systems running CentOS7.4 on KVM.  Shorewall 5.0.14.1.  
Communication with DMZ by a virtual private bridge built in virt-manager, and 
communication between LAN machines is by SRIOT ethernet hardware.

The router is a VM with 3 interfaces -- fiberoptic, LAN, DMZ. -- and I followed 
the doc for 3 interface, setting the SNAT file:
.MASQUERADE  10.1.111.30/32,192.168.1.0/24   eth1
(DMZ: 10.  LAN: 192.)

LAN masquerades through the router fine.  From the router I can ping the dmz 
and ssh to it just fine.

Problem is the dmz machine can't ping out;  can't even get nameservice.  And 
dmesg in both the dmz and router show -nothing- in dmesg.

Also I can't ssh from the lan to the dmz machine.  I can ping it from the 
router, and ssh in, but not from the LAN.--
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
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users