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 > <https://wiki.strongswan.org/projects/strongswan/wiki/NatTraversal>, 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
