IPSec Tunnel - Ping Working, but other protocols fail

Hello all,

I am new to the forum and MikroTik devices in general. I hope therefor I do not ask completely stupid questions.
My issue is similar to this thread, but was not resolved as mentioned : http://forum.mikrotik.com/t/ipsec-site-to-site-can-ping-but-no-other-traffic-flows/96273/1

My IPSec tunnel is enabled between myself (RB2011UiAS) and a cloud provider which device I do not control. I have verified the IPSec policy however does match my own. The tunnel is established fine and I am able to send ICMP traffic to various hosts on both sides.

I have tried removing all DROP rules and I have opened all ports/protocols.

My challenge however is getting any other traffic to work:

  • RDP traffic just states “An internal error has occured”
  • HTTP - when I browse a HTTP page on the remote network the page is partially loaded and then just stops mid-load (with the browser status indicating that it’s trying to continue loading)

I have applied FORWARD rules to allow all traffic between the two network as well as a SRCNAT from my network to the remote network.

FIREWALL CONFIG:
add chain=input comment=“Allow Limited ICMP for input” limit=50,5:packet protocol=icmp
add chain=forward dst-address=192.168.88.0/24 limit=50,5:packet src-address=172.16.110.0/24
add chain=forward dst-address=172.16.110.0/24 src-address=192.168.88.0/24
add action=drop chain=input comment=“Drop excess ICMP input traffic” protocol=icmp
add chain=input comment=“defconf: accept establieshed,related” connection-state=established,related
add chain=input comment=“allow ipsec” dst-port=500 protocol=udp
add chain=input comment=“allow l2tp” dst-port=1701 protocol=udp
add chain=input comment=“allow pptp” dst-port=1723 protocol=tcp
add chain=input comment=“allow sstp” dst-port=443 protocol=tcp
add action=drop chain=input comment=“defconf: drop all from WAN” in-interface=ether1 log-prefix=“DROP - 8 -”
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related
add chain=forward comment=“defconf: accept established,related” connection-state=established,related
add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid log-prefix="DROP - 11 - "
add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat
connection-state=new in-interface=ether1 log-prefix=“DROP - 12 -”
/ip firewall mangle
add action=change-mss chain=forward dst-address=172.16.110.0/24 new-mss=1200 protocol=tcp tcp-flags=syn
/ip firewall nat
add chain=srcnat comment=“allow datacentre NAT” dst-address=172.16.110.0/24 log=yes log-prefix="NAT - "
src-address=192.168.88.0/24
add action=masquerade chain=srcnat comment=“defconf: masquerade” out-interface=ether1
add action=masquerade chain=srcnat comment=“masq. vpn traffic” src-address=192.168.89.0/24

IPSEC CONFIG:
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-192-cbc,aes-192-ctr
/ip ipsec peer
add address=41.77./32 enc-algorithm=aes-256,aes-192 secret=*******
/ip ipsec policy
add dst-address=172.16.110.0/24 sa-dst-address=41.77.***** sa-src-address=154.0.***** src-address=192.168.88.0/24
tunnel=yes

Any ideas of what I can try?

Make and input and forwarding rule that allows from the IP of the “other device”. So the WAN IP.

Add rules for input and forwarding of the subnet from which the other device sends traffic.

Thx for the suggestion. This however did not resolve the issue. I can report that using a different VPN end-point at the cloud provider fixed the issue. Not sure at present what the problem was - if we figure it out with the vendor I will post it here for someone else’s benefit. Good news is the tunnel was fine :laughing: