rabienz
February 10, 2026, 3:43pm
1
i have a problem in OS7
[admin@MikroTik] > ping 192.168.10.17 src-address=192.168.20.254
[admin@MikroTik] >
i set policy on mikrotik
I also tried to set ipsec out none in masquerade rule with no luck
Any chance i can make this vpn work?
thanks in advance
jaclaz
February 10, 2026, 5:13pm
2
rabienz:
TTL exceeded
Should mean that TTL exceeded
Try running a traceroute, maybe it show what happens.
Normally TTL is more than adequate, exceeding it is usually the result of a routing loop of some klnd.
rabienz
February 10, 2026, 7:57pm
3
thank you for your answer, so how to fix my problem ?
sindy
February 10, 2026, 8:14pm
4
IPsec has some specific behavior - it matches packet headers against IPsec policy traffic selectors as the very last step before sending a packet via the out-interface chosen by normal routing.
And when the router itself sends a packet that is not a response, it only sets its source address after routing - routing finds the out interface and the packet gets the primary address of that interface as a source, unless a pref-src parameter of the route used indicates a different one.
Your IPsec policy matches on src-address=192.168.20.0/24, but the default route most likely goes via the WAN interface so the packet gets the WAN IP as its source address, and hence it doesn’t match your policy. So if you only need pinging from the router for testing, specify src-address as a parameter of the ping, but make sure that src-nat or masquerade won’t change it - I don’t know your nat rules so they may or may not care about this. Transit traffic from connected devices in 192.168.20.0/24 will have an address that matches the policy, but you also have to make sure that src-nat or masquerade doesnt change it.
When you ping from the Forti side, the Mikrotik responds from the same address at which it has received the request and nat rules are only used to handle the initial packet of each connection, so even the exemption from src-nat is not necessary.
rabienz
February 10, 2026, 8:22pm
6
Thank you Sindy for you informative question,
sindy
February 10, 2026, 8:29pm
7
If so, use /export hide-sensitive file=some-nice-name, then download some-nice-name.rsc, use your favourite text editor’s “find and replace” function to systematically replace the first two bytes of any public addresses with something like psub.a. (public subnet A), psub.b. etc. (to preserve consistency between addresses in the same subnet) and also obfuscate any usernames for 3rd party services, serial numbers, MAC addresses… as hide-sensitivedoesn’t hide everything, only passwords and private keys. Then copy-paste the the result to the post between two ` signs (or use the</>button).
But the way you describe it, the srcnat rules seem to be the most likely issue.
rabienz
February 10, 2026, 8:31pm
8
/interface ethernet
set default-profile=PPTP
add add-default-route=no comment="VSAT2 DHCP (FortiGate port10)"
/ip route
sindy
February 10, 2026, 9:16pm
9
Please edit the post above and use the </>key to change the appearance of the configuration block.
The rule add action=accept chain=srcnat comment="NO-NAT TIME 20->10" dst-address=192.168.10.0/24 src-address=192.168.20.0/24 is on a correct position in chain srcnat so the issue you hit when pinging from the router itself and do not specify the source address is a different one than what you hit when pinging from a connected device - you can see that the ping from the router itself succeeds when you specify src-address=192.168.20.254. So the action=accept rule in srcnat does its job properly and the IPsec policy and SA are also working properly, and the issue must be either in the firewall (filter or raw, but I cannot see anything that would drop traffic from 192.168.20.0/24 to 192.168.10.0/24 there) or outside (a missing/wrong route to 192.168.10.0/24 via 192.168.20.254 on the external device you are pinging from). How does tracert 192.168.10.17 (Windows) or traceroute 192.168.10.17 (Linux/MacOS) look like on the external device?
rabienz
February 11, 2026, 10:08am
10
it seems it is working from .20 subnet and i was trying from different vlan 172.16.200.0 and thats why it was not working
sindy
February 11, 2026, 11:11am
11
You might want to clean up functional or verbatim duplicities - two rules accept everything that matches ipsec-policy=in,ipsec, another rule accepts everything that matches ipsec-policy=out,ipsec, but on top of these you also accept the same traffic using rules that match on src-address and dst-address.
You might save a tiny bit of CPU throughput by moving the rule action=accept chain=forward comment="VPN - Lan access" src-address=10.99.99.0/24 after (below) the action=accept chain=forward comment="FW: allow established/related" connection-state=established,related one in filter.
You also use a mix of “selective accept” and “selective drop” approaches in filter, which is useful in “single screen” firewalls but makes debugging of more complex ones extremely complicated. I personally prefer the selective accept one, i.e. drop everything that you haven’t explicitly accepted: your legal users let you know quickly if you forget to permit something, whereas your illegal users never let you know if you forget to block something.
Last, these two rules in mangleonly make sense if there are some IPsec peers in your LAN, as packets sent by the router itself do not pass through prerouting:
action=mark-routing chain=prerouting comment="IPsec IKE to WAN1" dst-address-list=IPSEC_PEERS dst-port=500,4500 new-routing-mark=to_cyberia passthrough=no protocol=udpaction=mark-routing chain=prerouting comment="IPsec ESP to WAN1" dst-address-list=IPSEC_PEERS new-routing-mark=to_cyberia passthrough=no protocol=ipsec-esp
And as you don’t have any public LAN subnet, handling transit of bare ESP doesn’t make sense at all - did this rule ever match a packet?
.
