Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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\

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

> 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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

> 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

Re: [Shorewall-users] IPSec Tunneling

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 

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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 

Re: [Shorewall-users] IPSec Tunneling

> 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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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,

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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 >

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

> 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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

Re: [Shorewall-users] IPSec Tunneling

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

[Shorewall-users] IPSec Tunneling

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