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 >
signature.asc
Description: OpenPGP digital signature
