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

[Tom Eastep]

On 01/07/2018 01:09 PM, Tom Eastep wrote:

> 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 + 208 = 736.
  ---

Make that 708.

-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
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Tom Eastep]

On 01/07/2018 11:12 AM, Colony.three via Shorewall-users wrote:
> 
>> 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.

Bummer.

> 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 + 208 = 736.

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

Yes -- you will need SNAT on Zeta.

-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
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
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

[Tom Eastep]

On 01/07/2018 09:48 AM, Tom Eastep wrote:

>>
>> Libreswan is supposed to automatically handle DNAT-T and clearly it does
>> as it works when not changing ports.  And changing ports in this way
>> should not be visible to it unless there's some damage in the
>> decapsulation process.
>>
> 
> There is no encapsulation going on at this point, but I have also
> confirmed that it doesn't work. I can only assure you that this isn't a
> Shorewall issue, as there are no options to the iptables DNAT target
> that are remotely relevant to this problem.
> 

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
-- 
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
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Tom Eastep]

On 01/07/2018 09:13 AM, Colony.three via Shorewall-users wrote:
> 
>> 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 

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

[Tom Eastep]

On 01/06/2018 04:57 PM, Colony.three via Shorewall-users wrote:

> So I told the doctor, "Doc, when I move my arm this way, it hurts."  The
> doc says, "well then don't move your arm this way."
> 
> You're better than that Tom, although you may not admit it.  Maybe
> you're angry with me for my frustration over Strongswan, but that is not
> relevant anymore.  This no longer has anything to do with Strongswan.>
> There are a hundred million bots trying everything on common ports, with
> known vulns as well as zero-days.  They can not try every port so 99% of
> them concentrate on the low-hanging fruit.  I am in enterprise infosec,
> and security is layering. 
> 
> It would be best if I could change this port, and there is some reason
> that my packets are getting torn up.  Maybe you don't have the answer
> but maybe someone will recognize the merit of this effort and will pitch
> in.  This is the only place to ask about the mechanics of Shorewall
> after all.
>

I admit that this is one of the few of your 50+ posts in the last two
weeks that directly relates to Shorewall, but I'm afraid that I couldn't
write a DNAT rule that shortens the payload of a packet if I tried. So I
have no clue what is going on in this case. Have you tried comparing the
packets arriving from the net with those being sent to the IPSEC endpoint?

-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
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

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

[Tom Eastep]

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: DNAT    net
>>> local:192.168.1.16:500  udp  -  5500    DNAT   
>>> 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:2

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.178:19924: Received 
packet with mangled IKE header - dropped
Jan  5 15:31:55 zeta pluto[54167]: packet from 172.58.43.178:19924: length of 
ISAKMP Message is smaller than minimum
Jan  5 15:31:55 zeta pluto[54167]: packet from 172.58.43.178:19924: Received 
packet with mangled IKE header - dropped
Jan  5 15:31:58 zeta pluto[54167]: packet from 172.58.43.178:19924: length of 
ISAKMP Message is smaller than minimum
Jan  5 15:31:58 zeta pluto[54167]: 

Re: [Shorewall-users] IPSec Tunneling

[Tom Eastep]

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:
>> DNAT    net local:192.168.1.16:500  udp  - 
>> 5500   
>> DNAT    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
-- 
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
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[Tom Eastep]

On 01/05/2018 02:46 PM, Colony.three via Shorewall-users wrote:
> 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)

Yes.

-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
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

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

[Tom Eastep]

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:
> DNAT    net local:192.168.1.16:500  udp  -  5500   
> DNAT    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
-- 
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
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
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] IPSec Tunneling

[Tom Eastep]

On 12/15/2017 12:58 PM, Colony.three via Shorewall-users wrote:
> 
>>
>>> 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? 

Only if you have more than one outside IP.

>>
>> If so, would this be the router's outside IP? 

Yes, again if there are more than one and you only want to accept IKE
connections to one of them.

>> Could I do a command
>> substitution like $(curl ipinfo.io/ip ) ?
> 

No -- but you can use a Shorewall address variable like  See
http://www.shorewall.org/configuration_file_basics.htm#AddressVariables

-Tom
> 
> 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
> 


-- 
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
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
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) ?

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

[Tom Eastep]

On 12/15/2017 09:41 AM, Colony.three via Shorewall-users wrote:
> 
>> 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
> , and
> I'm trying to understand that now.
> 

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
-- 
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
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
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

Re: [Shorewall-users] IPSec Tunneling

[cacook]

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.


On 12/14/2017 11:14 PM, Bill Shirley wrote:
> This statement sounds like you think that if your IPSEC is
> compromised, the h@x0r will
> now have a session on the system (VM or native).  Even if someone
> could inject traffic,
> it would be just a decrypted packet with a SRC= and a DST= that still
> needs to be routed.
> That packet must pass the rules.  VM or not, how do you determine a
> packet is invalid?
>
> If you're specific in tunnels with the GATEWAY column, a foreign
> packet will not be accepted.
> #TYPE   ZONE GATEWAY(S)  GATEWAY
> # ZONE(S)
> ?COMMENT siteA tunnel
> ipsec   inet    xxx.yyy.zzz.123
>
> Also, a foreign esp packet can also be dropped in the mangle
> PREROUTING chain:
> CONTINUE:P          xxx.yyy.zzz.123 this.fw.addr.456        esp    #
> my pal siteA
> DROP:P              -                    -      esp    # I don't
> know you!!
>
> Bill
>
> On 12/14/2017 5:55 PM, cac...@quantum-sci.com wrote:
>> 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.
>
>
> --
>
> 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

--
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

[Bill Shirley]

This statement sounds like you think that if your IPSEC is compromised, the 
h@x0r will
now have a session on the system (VM or native).  Even if someone could inject 
traffic,
it would be just a decrypted packet with a SRC= and a DST= that still needs to 
be routed.
That packet must pass the rules.  VM or not, how do you determine a packet is 
invalid?

If you're specific in tunnels with the GATEWAY column, a foreign packet will 
not be accepted.
#TYPE   ZONE GATEWAY(S)  GATEWAY
# ZONE(S)
?COMMENT siteA tunnel
ipsec   inet    xxx.yyy.zzz.123

Also, a foreign esp packet can also be dropped in the mangle PREROUTING chain:
CONTINUE:P          xxx.yyy.zzz.123 this.fw.addr.456        esp    # my pal 
siteA
DROP:P              -                    -      esp    # I don't know you!!

Bill

On 12/14/2017 5:55 PM, cac...@quantum-sci.com wrote:
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.



--
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

[Tom Eastep]

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
>>> 
>>>
>>> - 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 -o  -j MASQUERADE

during boot.

-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
  \___



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] IPSec Tunneling

[cacook]

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






--
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

[Tom Eastep]

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
> 
>
> - 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

-- 
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
  \___




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
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