The reason is that packets are properly routed to the on premises machines, but those same machines do not know where to send their answers back to Azure clients.
Correct, yes. But that does not mean you have to configure the route on every machine.
I just had the exact same issue and I solved it like this:
Environment:
1 Azure Subscription with 1 VNet with 1 Dynamic VPN Gateway.
1 RRAS Server on Premise behind my Router, routing the IPSEC Ports to the RRAS Server (I know, bad setup, NOT supported by Microsoft, but still works if you do the correct port forwarding).
All Default Gateways on all on Premise Machines are set to the Router, not the RRAS Server.
Situation:
Exactly the same as you. VPN is set up and connected.
Connecting to the Azure Machines from the RRAS Server works, connecting to the RRAS IP's from the Azure Machines works too.
What doesn't work is connecting to the Azure Machines from another on Premise Machine and connecting to another on Premise Machine from Azure Machines.
Resolution:
As you stated yourself, the on Premise Machines don't know how to connect to the Azure subnet. But instead of configuring this static route on all the on Premise Machines, I created just 1 static route on my Router, pointing the Azure Subnet to my RRAS Server. Magic Magic, all connections from all Machines on Premise to Azure and vice versa started working like a charm.
Of course, the smoothest solution would be to use your default gateway router to connect to the Azure network as this would solve the "my normal default gateway doesn't know of azure" problem.
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
Cyberoam has given the solution for firmware 10.0 onwards. The detailed explanation is given on this URL http://kb.cyberoam.com/default.asp?id=2936&Lang=1