So I've managed to figure this out after a lot of digging around, I am able to use the native Azure Site-to-Site VPN functionality with OpenSwan which runs on a linux box (Raspberry Pi/Arch Linux) behind my home network's NAT router.
Network topology:
- 192.168.0.0/24 - Home network
- 192.168.1.0/24 - Azure network
- 192.168.0.1 - Home router's private IP
- 192.168.0.2 - Linux box acting as the home network's VPN server and gatewat
Firstly I set up Azure with:
- It's remote network as normal
- My local network with the VPN address as my public IP
- Enabled the Site-to-Site checkbox on the Azure network linking it to my local network
- Created a static gateway so IKEv1 is used
On my home network's router I forwarded the following to my Linux gateway running Openswan (192.168.0.2):
- UDP 500
- UDP 4500
- Protocol 50 (GRE)
My ipsec.conf looks like this:
version 2.0
config setup
nat_traversal=yes
virtual_private=%4:192.168.0.0/24
protostack=auto
interfaces="ipsec0=eth0"
conn azure
authby=secret
auto=start
type=tunnel
left=192.168.0.2
leftsubnet=192.168.0.0/24
leftnexthop=192.168.0.1
right=<azure's VPN gateway IP>
rightsubnet=192.168.1.0/24
ike=3des-sha1-modp1024,aes128-sha1-modp1024
esp=3des-sha1,aes128-sha1
pfs=no
ipsec.secrets:
192.168.0.2 <azure vpn gateway> : PSK "Azure's PSK"
That got the link up and running, to allow routing between sites (both ways after a lot of frustration):
/etc/sysctl.conf:
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
A bash script that runs on boot to keep 'ipsec verify' happy:
#!/bin/bash
for vpn in /proc/sys/net/ipv4/conf/*; do
echo 0 > $vpn/accept_redirects;
echo 0 > $vpn/send_redirects;
done
sysctl -p
Finally my iptables rules which took the most amount of fiddling:
filter table, this allows the home network to connect to Azure and allows the connection to be established, but Azure VM's still aren't yet able to connect to home network servers:
-A FORWARD -s 192.168.1.0/24 -m policy --dir in --pol ipsec -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -m policy --dir out --pol ipsec -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -m policy --dir in --pol ipsec -j ACCEPT
-A INPUT -p esp -j ACCEPT
nat table, this allows the Azure VM's to connect to any machine on my home network:
-A PREROUTING -i eth0 -p udp -m udp --dport 4500 -j DNAT --to-destination <azure public vpn ip>:4500
-A PREROUTING -i eth0 -p udp -m udp --dport 500 -j DNAT --to-destination <azure public vpn ip>:500
-A POSTROUTING -o eth0 -j MASQUERADE
With all this I can ping and communicate in both directions, all Azure VM's can see my home network, all home network machines can see my Azure VM's.
The Azure side routes correctly on it's own, for my home network I set up a static route in my router to send 192.168.1.0/24 to 192.168.0.2 but for testing on my machine I just created a static route:
route -p ADD 192.168.1.0 MASK 255.255.255.0 192.168.0.2 METRIC 100
I hope at least someone finds this useful, getting this set up has taken a long time and there isn't a good complete guide out there just a mixture of solutions which partially work.
Best Answer
Please have a look at the following:
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices
According to the documentation, assuming all of your network information is correct, you should disable
Perfect Forward Secrecyif you are using static routing.