[strongSwan] Routing/iptables issue - Help with configuration

[Noel Kuntze]

Hi,

Fix your MASQUERADE rule in the *nat table.
Check the page about Forwarding and Split-Tunneling[1] for information about that.

Anyway: Your iptables rules don't provide any security. And those two rules are jus utter garbage:

> -A INPUT -m state --state NEW -m udp -p udp --dport 50 -s 40.X.Y.206/32 -j ACCEPT
> -A INPUT -m state --state NEW -m udp -p udp --dport 51 -s 40.X.Y.206/32 -j ACCEPT
You need to accept -p esp, not any UDP ports.

And that is just unreliable.
>  auto=start

Use auto=route instead and don't use closeaction or dpdaction with it, if you can help it.


Kind regards

Noel

[1] https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#General-NAT-problems

On 23.01.2018 04:32, Steve Paul wrote:
> Greetings,
>
> I've inherited a dual-homed CentoOS v6 box that I've been tasked with adding a site-to-site to Azure VPN Gateway using strongswan.
>
> The good news is- it works, but just one way.   I'm fairly confident I'm missing something with the iptables rules as the assets in Azure can ping, ssh and use services on the local lan, but the assets and gateway on the local site network with strongswan cannot.
>
> Info on the set up:
>
> Strongswan gateway:  eth0 - 10.0.2.1, network 10.0.2.1/23, eth1 - 38.X.Y.97 / public interface
>
> Azure gateway: virtual lans= 10.1.0.0/24, 10.2.0.0/24 - 40.X.Y.206 public interface
>
> This server already has a site-to-site with OpenVPN to another office (10.0.5.0/24), as well as a bunch of PC/Mac users using OpenVPN Access Server.   It also is being used as a network appliance with several 10.0.2.X assets using NAT on aliased interfaces on the 38.X.Y.0/24 network (public IP's).
>
> strongswan is using ikev2 and the two connect.  It was fairly trivial to make the connection config.  I also attached this config for anyone interested or if I need something additional to make this work.  Both Azure and the strongswan logs show init and child sa's are happy and PSK is working for both.  And as I said, anything in the Azure network can ping, ssh, ftp or http/https to anything in the 10.0.2.0/23 network.   The reverse is routing to the default on the gateway server to the internet (it's default gateway is 38.X.Y.29), Example:
>
> $ ping 10.1.0.4
> PING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.
> From 38.X.Y.29 icmp_seq=1 Destination Net Unreachable
> From 38.X.Y.29 icmp_seq=2 Destination Net Unreachable
> From 38.X.Y.29 icmp_seq=3 Destination Net Unreachable
> ....  38.X.Y.29 is the ISP router to the internet
>
> The strongswan routes look "normal" to me, so it has to be the NAT tables of the other stuff going on that is likely the culprit:
>
> # ip route show table 220
> 10.2.0.0/24 via 38.X.Y.96 dev eth1  proto static  src 10.0.2.1
> 10.1.0.0/24 via 38.X.Y.96 dev eth1  proto static  src 10.0.2.1
>
> I attached the default iptables which my bet is I'm missing something there preventing the interface from routing from the strongswan policy.  It's greatly abridged as I spared (only) all the NAT hosts through to public IP's.  Also, keep in mind that OpenVPN Access server adds/removes new entries as remote VPN users connect and drop but nothing out of the ordinary as they have their own interfaces (as0tX devices).
>
> What am I missing?   Thanks in advance!
>
>
> Warmest regards,
>
> Steve Paul
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180123/68b64099/attachment.sig>