no ping from onprem to Azure

RouterOS General
1

hello guys I follow this link to create the site to site https://blogs.technet.microsoft.com/netgeeks/2017/07/11/creating-a-site-to-site-vpn-ipsec-ikev2-with-azure-and-mikrotik-routeros/
I try all but the ping only response from azure to On Prem, can you help me to figure out what its going on. THANKS!!!

My configuration, Mikrotik V6.45.7
/ip firewall filter>
0 ;;; AZURE ACCES TO ROUTER
chain=forward action=accept src-address=192.168.20.0/24 dst-address=10.4.0.0/16 log=no
log-prefix=“” ipsec-policy=in,ipsec

1 ;;; PErmitir conexion IPSEC
chain=input action=accept protocol=ipsec-esp src-address=104.209.191.20 log=no log-prefix=“”

2 chain=forward action=accept src-address=10.4.0.0/16 dst-address=192.168.20.0/24 log=no
log-prefix=“”

/ip firewall nat
1 chain=srcnat action=accept src-address=192.168.20.0/24 dst-address=10.4.0.0/16 log=no
log-prefix=“”
2 chain=srcnat action=accept src-address=10.4.0.0/16 dst-address=192.168.20.0/24 log=no

/ip firewall mangle
;;; AZURE
chain=forward action=change-mss new-mss=1350 passthrough=yes tcp-flags=syn protocol=tcp
dst-address=10.4.0.0/16 log=no log-prefix=“”
/ip ipsec policy

PE TUN SRC-ADDRESS DST-ADDRESS

0 A ZU yes 192.168.20.0/24 10.4.0.0/16
/ip ipsec proposal
name=“AZURE” auth-algorithms=sha1 enc-algorithms=aes-256-cbc,aes-128-cbc lifetime=7h30m
pfs-group=none
/ip ipsec peer
name=“ZURE” address=104.209.191.20/32 profile=AZURE exchange-mode=ike2 send-initial-contact=yes
/ip ipsec profile
name=“AZURE” hash-algorithm=sha1 enc-algorithm=aes-256,aes-128 dh-group=modp1024 lifetime=8h
proposal-check=obey nat-traversal=no dpd-interval=2m dpd-maximum-failures=5

2

First question : is your VPN working ?!
On the Mikrotik side, give some info on the PH2-state ? It is established ?
You have 2 SA’s / SPI’s “installed” ? (1 in each direction) to form the IPSEC-tunnel ?

I have such IPSEC VPN running to Azure for months now without any issue actually.

3

Hello

First question : is your VPN working ? yes
On the Mikrotik side, give some info on the PH2-state ? It is established ?
ip ipsec active-peers> print

ID STATE UPTIME PH2-TOTAL

0 R 104.209.191.20 established 13h51m42s 1

You have 2 SA’s / SPI’s “installed” ? (1 in each direction) to form the IPSEC-tunnel ?

E spi=0x124904A src-address=104.209.191.20 dst-address=190.248.147.204
state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256
auth-key=“aa986059ea49ed04e1300f80e352b11365f38f30”
enc-key=“c945ea61b12f73a2415a254d1aa56d378d26c22f0bdd5373d0989e39bb70bb62”
add-lifetime=6h6s/7h30m8s replay=128

1 E spi=0x66CF6D72 src-address=190.248.147.204 dst-address=104.209.191.20
state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256
auth-key=“b2f528b9029c20f910fa2ff0338ef7bf4a70616b”
enc-key=“c8eedfa453516f776f921c25412c579176456f6f81cb13f2e86db073a90f8d78”
add-lifetime=6h6s/7h30m8s replay=128

4

My case is slightly different as I do not allow any new/originated traffic from Azure to my home-lab.
From my home-lab Linux boxes, I can reach Azure machines just fine with all the rules & settings above.
Slightly changes some IP’s for sanitation reasons.
I do see some settings are slightly differentr, but it appears your IPSEC-VPN is actually up and passing traffic (from Azure → Onprem)
172 = Homelab
192 = Azure VNET Subnet

Hope this helps.


/ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; Azure IPSEC VPN
chain=srcnat action=accept src-address=172.29.46.0/24 dst-address=192.168.0.0/16 log=yes log-prefix=“AZURE”


/ip firewall nat> /ip ipsec peer
/ip ipsec peer> print
Flags: X - disabled, D - dynamic, R - responder
0 name=“Azure” address=40.118.44.119/32 local-address=92.179.151.160 port=500 profile=default exchange-mode=ike2 send-initial-contact=no

/ip ipsec peer> /ip ipsec profile
/ip ipsec profile> print
Flags: * - default
0 * name=“default” hash-algorithm=sha1 enc-algorithm=aes-128,3des dh-group=modp2048,modp1024 lifetime=1d proposal-check=obey nat-traversal=yes dpd-interval=disable-dpd


/ip firewall mangle
Flags: X - disabled, I - invalid, D - dynamic
0 chain=forward action=change-mss new-mss=1360 passthrough=yes tcp-flags=syn protocol=tcp src-address=172.29.46.0/24 dst-address=192.168.0.0/16 log=no log-prefix=“”


/ip ipsec profile> /ip firewall filter
/ip firewall filter> print

Flags: X - disabled, I - invalid, D - dynamic

18 ;;; Azure VPN ESP
chain=input action=accept protocol=ipsec-esp src-address=40.118.44.119 in-interface=MyISP log=yes log-prefix=“AZURE-VPN-18”

19 ;;; Azure VPN Other
chain=input action=accept protocol=udp src-address=40.118.44.119 in-interface=MyISP dst-port=500,4500,800,1701 log=yes log-prefix=“AZURE-VPN-19”

24 ;;; AZURE:Accept Established/Related Packets
chain=forward action=accept connection-state=established,related src-address-list=IPSECAZURE in-interface=MyISP log=no log-prefix=“”

26 ;;; AZURE:Drop Invalid / Unrelated
chain=forward action=drop connection-state=invalid,new,untracked src-address-list=IPSECAZURE in-interface=MyISP log=yes log-prefix=“AZURE-VPN-26”


This address-list “IPSECAZURE” contains the 192.168.0.0/16 Azure subnet.

5

First of all, can you please re-word this? When you ping, from the azure subnet, an address in the onprem subnet, do you get a response from onprem? And when you ping, from the onprem subnet, an address in azure subnet, do you get a response from azure? When pinging from azure, do you ping the own address of the Mikrotik itself in the onprem subnet or an address of some other host?

Next, please post a complete export of your Mikrotik configuration. In most cases the mistake is in the part of the configuration which you don’t post because you assume it is unrelated.

6

When you ping, from the azure subnet, an address in the onprem subnet, do you get a response from onprem? yes
And when you ping, from the onprem subnet, an address in azure subnet, do you get a response from azure? NO
When pinging from azure, do you ping the own address of the Mikrotik itself in the onprem subnet or an address of some other host? I can PInging the mikrotik own address, and every ip from my sybnet

7

hello I am going to reviw your configuration, tkns

8

Most important: your firewall rules do not protect you against anything, because in /ip firewall filter, both chain=input and chain=forward do not end with a “drop the rest” rule. In RouterOS, the default handling in all chains is “accept”, so a packet which hasn’t matched any of the rules in the chain is accepted. Combined with having http and winbox open to the world, this is a dangerous setup. I’d strongly recommend to add at least an action=drop in-interface=ether1 rule as the last one to both chains, except if you are only able to access the machine remotely; if you depend on remote access, first place a rule allowing access to the winbox TCP port only from a src-address-list of known addresses and subnets from which you need to access the machine to the input chain of /ip firewall filter and only then add the “drop all” rule to its end, otherwise you’ll lock yourself out. And consider setting up a VPN for management access. I hope at least your public IPs in the configuration export aren’t the real ones. Connecting to HTTP via internet is insecure even with restriction to source addresses as the password encryption of HTTP authentication is ridiculously weak compared to today’s cracking methods and processing power available to the black hat guys, so anyone sniffing the network traffic can get your credentials.

To your original issue, as the problem is that the Azure side doesn’t respond to pings sent from Mikrotik side, I was looking for possible reasons and found nothing. The exception from the masquerade rule for src-address=192.168.20.0/24 dst-address=10.4.0.0/16 is in place, and nothing in chain=output and chain=forward of /ip firewall filter prevents packets from the Mikrotik’s LAN from being sent and matched by the IPsec policy. So I conclude it is some firewall setting at the Azure end. But to double-check, restart the IPsec connection. run /ip ipsec installed-sa print interval=1, and watch whether the SA from Mikrotik’s address towards the Azure address counts packets or not as you ping from LAN to Azure. If it counts, it is the firewall at Azure end; if it does not, something is wrong in your configuration but I cannot see it. If it counts while you don’t ping, disable anything at both ends that might send data across the IPsec link as there is no way to distinguish the ping attempts from other traffic (except maybe by packet size).