IPsec Tunnel: Ping and DNS Troubleshooting

IPsec Tunnel: Ping and DNS Troubleshooting

An IPsec tunnel that shows as established but fails to pass ping or DNS traffic is one of the most common RouterOS support questions. The tunnel handshake succeeds, but data packets never reach the remote side — or reach it but never come back.

This guide covers the root causes in order of frequency:

1. NAT masquerade overrides IPsec policy (most common)
2. IPsec policy selector mismatch (subnets don’t match actual traffic)
3. Firewall rules blocking forwarded tunnel traffic
4. FastTrack bypassing IPsec encryption
5. Policy routing / dual-WAN mangle conflicts
6. MTU / fragmentation (breaks large pings, DNS, and some apps)
7. DNS-specific issues (mode-config, split DNS, allow-remote-requests)

---

Prerequisites

• RouterOS 7.x
• A configured IPsec site-to-site or road-warrior tunnel that shows peers as established
• Access to both sides of the tunnel (or at least your side with logs)

---

Step 1 — Confirm the Tunnel Is Up

Before debugging data-plane issues, verify the control plane is healthy.

# Check peer negotiation status
/ip ipsec active-peers print detail

# Check installed Security Associations (SAs)
/ip ipsec installed-sa print detail

# Check policy state and packet counters
/ip ipsec policy print detail

• If active-peers is empty or state is not established, the problem is Phase 1/2 — see Phase 1 and Phase 2 troubleshooting before continuing here.
• If SAs are present but the packet and byte counters on matching policies stay at 0 while you generate traffic, the issue is that packets are not matching the policy (NAT, selector, or routing problem — continue below).
• If counters increment on the sending side but not on the remote, check firewall rules on the remote router.

---

Step 2 — Check for NAT Masquerade Conflicts

This is the most common cause of “tunnel up, no traffic”.

RouterOS applies NAT before IPsec policy matching. If a masquerade rule fires first, the source address changes — and the outgoing packet no longer matches the IPsec policy selector. The packet leaves in cleartext (or is dropped) instead of being encrypted.

Symptom

• Pinging from a LAN host behind the router fails.
• Policy counters stay at 0 on the sending side.
• Capturing traffic on the WAN shows the LAN subnet’s packets going out unencrypted (or not at all).

Fix — Add a NAT Bypass Rule

Add an action=accept srcnat rule that matches the traffic you want encrypted, and place it before the masquerade rule:

/ip firewall nat
add chain=srcnat \
    src-address=192.168.10.0/24 \
    dst-address=192.168.20.0/24 \
    action=accept \
    place-before=0 \
    comment="IPsec bypass — do not NAT VPN traffic"

Adjust src-address and dst-address to match your local and remote subnets. Repeat for each IPsec-protected subnet pair.

Verify rule order: Run /ip firewall nat print and confirm the bypass rule appears above the masquerade rule. NAT is first-match, so order is critical.

---

Step 3 — Verify IPsec Policy Selectors

The policy selector (local/remote subnet pair) must exactly match the source and destination of the packets you are testing.

Symptom

• NAT bypass is in place, but pings from the router itself fail while pings from LAN hosts work (or vice versa).
• Policy counters do not increment for your test traffic.

Testing from the Router Itself

When pinging from the RouterOS CLI, the router uses its own IP as the source. That IP may not be within the policy’s local selector. Always specify a source address that is inside the encrypted subnet:

/ping 192.168.20.10 src-address=192.168.10.1

Checking Policy Selectors

/ip ipsec policy print detail

Confirm that src-address and dst-address in the matching policy cover the actual source/destination of your traffic. Common mistakes:

• Policy is /24 but the LAN actually uses /23
• Remote subnet was entered with the host bits set (e.g., 192.168.20.5/24 instead of 192.168.20.0/24)
• A second policy is listed earlier and matching unexpectedly

---

Step 4 — Check Firewall Rules

Even with a working IPsec tunnel and correct NAT bypass, firewall filter rules can silently drop forwarded packets.

Add Accept Rules for IPsec-Protected Traffic

Use the ipsec-policy matcher to match traffic that is entering or leaving via IPsec:

/ip firewall filter
add chain=forward ipsec-policy=in,ipsec action=accept \
    comment="Accept inbound IPsec-decrypted traffic" \
    place-before=0
add chain=forward ipsec-policy=out,ipsec action=accept \
    comment="Accept outbound IPsec-to-encrypt traffic" \
    place-before=1

These rules must appear before any drop rules in the forward chain.

Temporary Logging to Find Drops

/ip firewall filter
add chain=forward \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    action=log log-prefix="IPSEC-OUT "
add chain=forward \
    src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    action=log log-prefix="IPSEC-IN "

Watch the log in real time:

/log print follow where message~"IPSEC"

If you see IPSEC-OUT entries but no IPSEC-IN entries, packets leave your router but do not come back — check the remote router’s firewall and policy.

---

Step 5 — Disable FastTrack for IPsec Traffic

FastTrack connection acceleration bypasses the normal packet processing path, which means FastTracked packets skip IPsec policy matching entirely. The tunnel shows as established and pings from the router itself may work, but traffic forwarded from LAN hosts disappears.

Symptom

• LAN-to-LAN traffic fails but router-originated pings succeed.
• Policy counters are zero for LAN traffic even though NAT bypass and selectors look correct.
• Issue appears after FastTrack was enabled or after a RouterOS upgrade.

Diagnosis

/ip firewall filter print stats where action=fasttrack-connection

If the packet counter on a fasttrack rule is climbing while IPsec policy counters stay at zero, FastTrack is intercepting the traffic.

Fix — Exclude IPsec Traffic from FastTrack

Add a connection-mark or destination-based exclusion before the FastTrack rule, or use the ipsec-policy matcher:

/ip firewall filter
add chain=forward ipsec-policy=out,ipsec action=accept \
    place-before=0 \
    comment="Accept IPsec-bound traffic before FastTrack"
add chain=forward ipsec-policy=in,ipsec action=accept \
    place-before=1 \
    comment="Accept IPsec-decrypted traffic before FastTrack"

Alternatively, scope the FastTrack rule to exclude the VPN subnets:

/ip firewall filter
set [find where action=fasttrack-connection] \
    src-address-list=!vpn-subnets dst-address-list=!vpn-subnets

---

Step 6 — Policy Routing / Dual-WAN Mangle Conflicts

If you use mangle rules to mark connections for load-balancing or dual-WAN failover, those routing marks can steer IPsec-bound traffic out the wrong interface before policy matching occurs. The result is that interesting traffic exits in cleartext via the wrong WAN.

Symptom

• Single-WAN config works; dual-WAN or PCC load-balance config breaks the tunnel.
• Sniffer on the wrong WAN interface shows unencrypted traffic that should be encrypted.
• Packet counters on the routing table show VPN traffic going to a non-default table.

Diagnosis

/routing rule print detail
/ip firewall mangle print detail where action~"mark-routing"
/ip route print detail where routing-table!=main

Fix — Exempt IPsec Traffic from Routing Marks

Add a prerouting mangle rule that accepts VPN-bound traffic before mark-routing rules fire:

/ip firewall mangle
add chain=prerouting \
    src-address=192.168.10.0/24 \
    dst-address=192.168.20.0/24 \
    action=accept \
    place-before=0 \
    comment="Skip routing marks for IPsec traffic"

Repeat for the reverse direction. The action=accept in mangle terminates further mangle processing for that packet, leaving it in the main routing table where the IPsec policy can match it.

---

Step 7 — MTU and Fragmentation

IPsec encapsulation adds overhead (typically 50–80 bytes for ESP + NAT-T headers). On a standard 1500-byte Ethernet MTU, this leaves less room for the payload, causing fragmentation or silent drops if ICMP “Fragmentation Needed” messages are filtered anywhere on the path.

Symptoms

• Ping with small packets works; large pings fail:

  /ping 192.168.20.10 src-address=192.168.10.1 size=100  # works
  /ping 192.168.20.10 src-address=192.168.10.1 size=1400 # fails

• TCP sessions connect but stall after the handshake (web pages load partially, SSH connects then hangs)
• DNS fails for large responses (A/AAAA work; MX, TXT, or DNSSEC responses time out)

Fix 1 — Clamp TCP MSS (Recommended for TCP)

This fixes TCP sessions but does not fix ICMP ping or UDP DNS fragmentation:

/ip firewall mangle
add chain=forward \
    protocol=tcp tcp-flags=syn \
    ipsec-policy=out,ipsec \
    action=change-mss new-mss=1300 \
    passthrough=yes \
    comment="Clamp TCP MSS for IPsec overhead"

Use new-mss=clamp-to-pmtu instead of a fixed value if path MTU discovery is reliable on your network:

/ip firewall mangle
add chain=forward \
    protocol=tcp tcp-flags=syn \
    action=change-mss new-mss=clamp-to-pmtu \
    passthrough=yes \
    comment="Clamp TCP MSS to PMTU"

Fix 2 — Lower Interface MTU

For tunnels where all traffic (including UDP and ICMP) is fragmented, set a lower MTU on the internal (LAN) interface so the router fragments before encapsulation rather than dropping:

/interface ethernet set ether2 mtu=1400

Adjust the interface name and MTU value to match your setup. A common starting point for policy-based IPsec with NAT-T is 1400.

DNS-Specific: Large UDP Responses

EDNS0 allows DNS responses larger than 512 bytes over UDP. With IPsec overhead these can fragment and be dropped. Options:

• Ensure allow-remote-requests=yes and DNS queries go to a server inside the IPsec policy (the IP must be covered by the selector).
• Force DNS over TCP (not directly configurable in RouterOS per-upstream, but supported by most resolvers on retry after UDP truncation).
• Set a lower EDNS buffer size on the querying resolver (external resolver config).

---

Step 8 — DNS for IKEv2 Road-Warrior Clients

For IKEv2 remote-access tunnels, DNS servers are pushed to clients via mode-config. If mode-config is missing or misconfigured, VPN clients resolve names through their local (non-VPN) DNS rather than the internal resolver. Client address pools are configured on the peer or identity, not on the mode-config entry itself.

Configure Mode-Config DNS Push

/ip ipsec mode-config
add name=rw-cfg \
    split-include=10.10.0.0/16
set [find where name="rw-cfg"] \
    system-dns=no \
    static-dns=10.10.0.53

Bind the mode-config to the matching identity:

/ip ipsec identity
set [find where auth-method=digital-signature] mode-config=rw-cfg

Enable the Router to Answer DNS Queries from VPN Clients

If the pushed DNS server is the router itself, enable remote requests:

/ip dns set allow-remote-requests=yes

Confirm with:

/ip dns print
/ip dns cache print

Verify a Client Received the DNS Configuration

After reconnecting the VPN client, check the VPN adapter’s DNS settings on the client OS. If the client shows its local resolver instead of the pushed server, mode-config was not applied — confirm the identity binding points to the correct mode-config profile.

Firewall Rule: Permit DNS from VPN Pool

Ensure the firewall allows UDP/TCP 53 from VPN client addresses to the DNS server:

/ip firewall filter
add chain=input protocol=udp dst-port=53 \
    src-address=<vpn-pool-subnet> action=accept \
    comment="DNS from VPN clients"
add chain=input protocol=tcp dst-port=53 \
    src-address=<vpn-pool-subnet> action=accept \
    comment="DNS from VPN clients TCP"

---

Diagnostic Command Reference

# Control plane
/ip ipsec active-peers print detail
/ip ipsec installed-sa print detail
/ip ipsec policy print detail

# Enable IPsec debug logging
/system logging add topics=ipsec,!packet action=memory
/log print follow where topics~"ipsec"

# Watch live traffic on WAN (expect ESP or UDP/4500)
/tool sniffer quick interface=ether1 ip-protocol=ipsec-esp duration=10
/tool sniffer quick interface=ether1 port=500,4500 duration=10

# NAT rule check
/ip firewall nat print detail

# Firewall stats
/ip firewall filter print stats

---

Troubleshooting Checklist

#	Check	Command
1	Peer established, SAs installed	/ip ipsec active-peers print
2	Policy counters increment when sending traffic	/ip ipsec policy print detail
3	NAT bypass rule above masquerade	/ip firewall nat print
4	Ping with correct src-address	/ping <remote> src-address=<local-lan-ip>
5	Policy selectors match exact subnets	/ip ipsec policy print detail
6	Firewall accept rules for IPsec forward chain	/ip firewall filter print
7	FastTrack not intercepting VPN traffic	/ip firewall filter print stats where action=fasttrack-connection
8	Routing marks not diverting VPN traffic	/ip firewall mangle print detail
9	Large ping fails, small ping works (MTU issue)	/ping <remote> src-address=<local> size=1400
10	IKEv2 clients: mode-config has static-dns set	/ip ipsec mode-config print detail
11	Router answers DNS for VPN clients	/ip dns print → allow-remote-requests=yes

---

See Also

• IPsec Site-to-Site VPN: Home to Cottage
• IPsec
• L2TP/IPsec with Multiple Clients Behind NAT
• Home/Cottage WireGuard VPN