Client to site IPSec negotiation traffic only one direction?

RouterOS General
1

Good morning from Wisconsin,

I’m trying to rebuild a “road warrior” client-to-site IPSec VPN after a Mikrotik failed its firmware update last Thursday and took parts of its config with it. Based on backups and past documentation, it’s set up correctly; however, the negotiation traffic only travels from the WAN inbound to the Mikrotik, and I can’t see any negotiation traffic leaving the Mikrotik per the screenshot below, so clearly negotiation fails and the connection is never established. We’ve set up dozens of these IPSec VPNs before, both site-to-site and client-to-site, and have never seen IPSec traffic only going one direction.

Where have we gone wrong in the setup?
Untitled.png

2

Most likely misconfigured firewall is causing this. Post your IPsec policy and firewall configuration.

3

Hi emils,

I have removed all the ‘disabled=yes’ lines, port forwarding rules, and those related to two other site-to-site VPNs. Here’s what’s left.

/ip ipsec peer profile
add dh-group=modp1024 enc-algorithm=3des name=profile_3

/ip ipsec proposal
set [ find default=yes ] enc-algorithms=3des

/ip ipsec peer
add address=0.0.0.0/0 exchange-mode=main-l2tp generate-policy=port-override passive=yes profile=profile_3 secret=XXXXXXXXXXX send-initial-contact=no

/ip ipsec policy
add dst-address=0.0.0.0/0 src-address=0.0.0.0/0 template=yes

/ip firewall filter
add action=accept chain=input in-interface=pppoe-out1 protocol=ipsec-ah
add action=accept chain=input in-interface=pppoe-out1 protocol=ipsec-esp
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input dst-port=4500 protocol=udp
add action=accept chain=input protocol=gre
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input protocol=ipsec-ah
add chain=input dst-port=500 protocol=udp
add chain=input dst-port=4500 protocol=udp
add action=accept chain=forward comment=“VPN traffic - Road warriors” dst-address=10.0.12.0/24 src-address=10.0.13.0/24
add action=accept chain=forward comment=“Accept forward established,related” connection-state=established,related
add action=accept chain=forward comment=“Accept forward established” connection-state=established
add action=accept chain=forward comment=“Accept forward related” connection-state=related
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related
add action=accept 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
add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat connection-state=new in-interface=pppoe-out1
add action=accept chain=input protocol=icmp
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input in-interface-list=!mactel

/ip firewall nat
add action=masquerade chain=srcnat comment=“Allow WAN-destined traffic from LAN” dst-address=10.0.12.0/24 src-address=10.0.12.0/24
add action=masquerade chain=srcnat out-interface=pppoe-out1 src-address=10.0.12.0/24
add action=masquerade chain=srcnat out-interface=pppoe-out1 src-address=10.0.13.0/24
add action=masquerade chain=srcnat comment=“defconf: masquerade” out-interface=pppoe-out1 out-interface-list=WAN src-address=10.0.12.0/24

4

What is the purpose of you nat rules?
I’m almost sure that one default masquerade rule is sufficient:

/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN

or

/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-out1
5

Good morning xvo,

You’re correct - this firewall had to be rebuilt from scratch last Thursday, so I moved all the default rules to the bottom and put ours to the top, and I haven’t taken the time to clean it up yet.