Azure Site-to-Site VPN using Mikrotik, cant access private IP from. Traffic flows only from Azure to Onprem

Hello,

I have an issue with the Azure site-to-site tunnel in conjunction with Mikrotik router. Set everything up using this https://blogs.technet.microsoft.com/netgeeks/2017/07/11/creating-a-site-to-site-vpn-ipsec-ikev2-with-azure-and-mikrotik-routeros/.

Everything works great, connection is established. I can access my on-premise infrastructure from Azure VMs, but not vice-versa.

Cant access Azure in any way (ping, RDP etc.). What could be the cause of that?
Disabled firewall in Azure VM, opened all ports in Azure VM networking properties (NSG). Disabled onpremise (Mirotik’s) firewall. Still is not working.

Am I missing some step. Is there other options that should be first set up in Azure or Mikrotik (open traffic for Azure VPN public IP address? Set static routes? new to this). Azure firewall, route tables are not created, everything is default. All ports are open in default NSG, that came with the VM.

You have to add additional NAT rule to access Azure from On-Premise -

/ip firewall nat
add action=accept chain=srcnat comment="Azure" dst-address=\
    azure-subnet/24 src-address=onprem-subnet/24

Also Azure suggests to clamp TCP MSS at 1350, so you should set this value by adding additional Mangle rule -

/ip firewall mangle
add action=change-mss chain=forward comment="Azure" dst-address=\
    azure-subnet/24 new-mss=1350 passthrough=yes protocol=tcp tcp-flags=syn

And if you want to access your Mikrotik router from Azure, you should add additional firewall rule -

add action=accept chain=input comment="Azure access to router" \
    dst-address=router-ip in-interface=*set-your-wan-port* ipsec-policy=in,ipsec \
    src-address=azure-subnet/24

Thank you Fesiit, for your answer.

Speaking about FW rules:

  • First srcnat rule that allows azure-onprem private ip networking was already there, however I can ping onprem network from azure even without that rule. Pings were not going at all before I created forward Filter rule where accept sourceaddress-azure-subnet, dst-address=onprem-subnet in order to get the traffic go through. And another filter rule with opposite settings to theoretically allow traffic back to the Azure which does not work.


  • Added TCP MSS clamp.


  • Did not add the last rule due router already being available in the Azure.

When pinging NAT rule does not show any activity, packets go thorugh only the Filer Rules. Azure onprem network does not “see” azures private network at all.

Connection still does not work. Tried turning off all drop rules but again with no luck.
I was digging and some people said that when creating those fw rules a flag before-fasttrack=0 (dont remember the exact value) has to be set, do you know anything about that?

First srcnat rule is not meant to allow Azure to On-Premise traffic, it is for On-Premise to Azure.

Basically with that srcnat, mangle rule and these default fw rules you should be able to access Azure from On-Premise and vice versa. I have many IPsec tunnels created from Mikrotik to Azure that way and everything works. Default firewall rules -

/ip firewall filter
add action=accept chain=input \
    connection-state=established,related,untracked
add action=drop chain=input \
    connection-state=invalid
add action=drop chain=input \
    in-interface-list=!LAN
add action=accept chain=forward \
    ipsec-policy=in,ipsec
add action=accept chain=forward \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward \
    connection-state=established,related
add action=accept chain=forward \
    connection-state=established,related,untracked
add action=drop chain=forward \
    connection-state=invalid
add action=drop chain=forward \
    connection-nat-state=\
    !dstnat connection-state=new in-interface-list=WAN

Thanks, i will check that out.
One other thing - I was wondering about the Routes. Should BGP be configured?

No, BGP should be configured only if you only really needs it. Also there’s no need for additional Routes from Azure side. With default NSG rules, Azure should allow IPsec traffic for both sides.

Okay, thanks for the info. No idea where to continue. I have a few spare devices, will try to set the VPN with a fresh device on different network.

Hello Fesiit, once again thanks for the help!

Today I found out that it was an ARP issue. Some time ago we set the ARP on all bridged ports to be proxy-arp, due to Apple devices dropping DHCP requests and not being able to connect. Turns out that setting fixes one thing and the breaks all the others (if you dont know how to use it properly).

Created a new interface for the local network that will be used for Azure and set the ARP to enabled. Traffic now fully goes to either of directions.

hello guys I have the same problem, I try all but the ping only response from azure to On Prem
My configuration, Mikrotik V6.45.7

/ip firewall filter>
Flags: X - disabled, I - invalid, D - dynamic
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