0

Using Azure gateway VPN I created a site to site connection with another vpn device (checkpoint) over which I have no control (customer endpoint).

I created the connection, using their public ip, declared the secret key and for local address space I discussed with the client what 'local' IP is desired from both sides. We agreed to an IP in the 172.0.0.0 range.

The gateway connection says succeeded/connected, and I see very little traffic in the data-out field (kb's not mb's).

However, when I try to ping the local address space (172.xxx.xxx.xxx) from my windows server 2016 VM I only get Request timed out-errors.

Do I need to create additional routes in windows? I tried adding route

  route -p ADD 172.xxx.xxx.xxx MASK 255.255.255.255 0.0.0.0

but the host is still unreachable.

Any Ideas? Thanks

EDIT: added some progress below

Thanks, I allowed the ping and I can now ping my VPN Gateway from my Azure VM (which is 10.XXX.XXX.4). I then added the route "route -p ADD 172.xxx.xxx.xxx MASK 255.255.255.255 10.XXX.XXX.4"

and via tracert I can see the 172 address is routed to/via de vpn gateway, but then it times out. Does this mean the issue now is on the on-premise side?

Edit 2

By now, when running the vpn diag. log I do see some traffic, but I still cannot reach the other side.

Connectivity State : Connected
Remote Tunnel Endpoint : XXX.XXX.XXX.XXX
Ingress Bytes (since last connected) : 360 B
Egress Bytes (since last connected) : 5272 B
Ingress Packets (since last connected) : 3 Packets
Egress Packets (since last connected) : 130 Packets
Ingress Packets Dropped due to Traffic Selector Mismatch (since last connected) : 0 Packets
Egress Packets Dropped due to Traffic Selector Mismatch (since last connected) : 0 Packets
Bandwidth : 0 b/s
Peak Bandwidth : 0 b/s
Connected Since : 9/18/2017 5:33:18 AM
  • Could you try to RDP your local PC, ICMP package may block by Firewall. – Shui shengbao Sep 14 '17 at 6:44
  • Or you could try to RDP Azure VM from your local PC? – Shui shengbao Sep 14 '17 at 6:47
  • Hi, could you do this successful? – Shui shengbao Sep 14 '17 at 7:09
  • I can RDP via my P2S VPN I have configured in parallel, the site-to-site connection is from my azure virtual network to a customer's network I have no control over. I can ping the vpn gateway now from within my azure VM. running 'tracert 172.xxxxx' from my Azure VM results in 1 line of 2ms, 6ms, 1ms, 10.XXX.XXX.4 (the gateway), and all other lines are timed out. – user2713516 Sep 14 '17 at 8:14
  • According to your description, it seems your custom network disable ICMP(There may be an edge network firewall implementation). I suggest you could test other service(such as RDP or http). – Shui shengbao Sep 14 '17 at 8:17
0

First of all, check if Windows Firewall is not blocking ICMP.

Search for Windows Firewall, and click to open it.

  1. Click Advanced Settings on the left.
  2. From the left pane of the resulting window, click Inbound Rules.
  3. In the right pane, find the rules titled File and Printer Sharing (Echo Request - ICMPv4-In).
  4. Right-click each rule and choose Enable Rule.

Second, make sure you have the proper routing in place. The servers in your on-premises environment need to know how to reach the Azure environment. If your gateway can ping the Azure servers and the other way around is also true, then it's all good except that the only device that know this route is your GW. Make sure the servers in your network know how to reach the Azure network as well by adding a route to the Azure network through the GW. Example:

Next hop is also on-prem VPN:

VMs -> Default Windows Gw/Vpn Device -> Azure VPN Gw
route -p add <azure_network> mask <azure_net_mask> gw <azure_vpn_gw_ip>

As your VMs next hop is usually the Default Windows Gw, this will make sure that the next hop to reach azure_network is the azure_vpn_gw_ip. Make sure the route tables (local gateway configuration in Azure) has your on-premises network segment as well.

  • Thanks, I allowed the ping and I can now ping my VPN Gateway from my Azure VM (which is 10.XXX.XXX.4). I then added the route "route -p ADD 172.xxx.xxx.xxx MASK 255.255.255.255 10.XXX.XXX.4" and via tracert I can see the 172 address is routed to/via de vpn gateway, but then it times out. Does this mean the issue now is on the on-premise side? – user2713516 Sep 14 '17 at 6:16
0

According to your description, it seems your custom network disable ICMP. There may be an edge network firewall implementation or Windows Firewall.

I suggest you could use test with other service (such as RDP or http). Also, you could use tcping to determine network connectivity.

For debug your issue, I suggest you could check your VPN gateway log, please refer to this link.

Update:

According to OP's VPN gateway log.

Connectivity State : Connected 
Remote Tunnel Endpoint : 
Ingress Bytes (since last connected) : 0 B 
Egress Bytes (Since last connected) : 107604 B 
Connected Since : 9/14/2017 6:35:28 AM

VPN tunnel did not configure correctly. You need check your VPN configure again.

  • Hi, see my updated answer – user2713516 Sep 18 '17 at 5:52
  • Currently, Ingres has litter packets. But when VPN is connected, by default, you don't add route table. It seems your VPN connection has some issue. But I am not sure what is the issue on your custom side or Azure side. – Shui shengbao Sep 18 '17 at 6:01
  • Thanks, ill contact the 'other side' and see what they can do with their configuration – user2713516 Sep 18 '17 at 6:11
  • @user2713516 Hi, do you solve this? – Shui shengbao Sep 25 '17 at 6:45
  • Hi, not yet, I'm waiting on the other party to review their side of the tunnel – user2713516 Sep 25 '17 at 13:14
0

What kind of VPN did you provision? If you're not using Basic, BGP will automatically set up the needed routes for you.

If it's basic, then you will need to set up a route table in Azure yourself to direct traffic to the correct network.

Set up the route table like this:

enter image description here

You should have the GatewaySubnet and your local subnet in the table with the next hop being the Virtual network gateway.

If that doesn't work, use the IP flow verify option to ensure traffic can get through your security groups. By default RDP should be reachable even if ping is not, so try different ports.

  • It's the basic tier, never knew something like that was needed...I'll have a look at it tomorrow, thanks – user2713516 Sep 17 '17 at 5:45
  • I created the routing table, and added the route, but then noticed via the Effective routes-page that the route already existed...so apparently that was already configured properly. – user2713516 Sep 18 '17 at 5:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.