I eventually found a solution to my problem. I hadn't realised it but RRAS has a built in firewall, which is not exactly brilliant. You would have thought that they would have dropped this for integration with the built in windows firewall - but no.
It has a sort of mini-firewall which requires you not only add an outbound rule for, say, http access but also an inbound rule for the responses to the outbound connections.
My error above was that I had only opened outbound http but hadn't included the second rule to permit responses. Seems a bit stupid to need to explicitly include this rule.
In any case, the various problems I had with this box are now solved.
Thanks
Ian
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
If you can get 2 IPs, it will be much easier. With SSL, it's difficult to have 2 sites using the same IP and port.
It is possible though. To do so you'll need to setup host headers over SSL. Here's a search that returns a number of good results.
Essentially, you'll need to use a single cert for both sites. For plain HTTP it's easy. Just add a host header for your website and leave SSTP with the empty host header.
As for why 443 doesn't work for you now, it sounds like there may be a software (i.e. windows firewall) or hardware firewall in front of your web server. See if it works from the local machine. If it does, then it's a firewall issue. If it doesn't, then it's not configured correctly in IIS.