Dear Forum Members!
I’m looking for help to solve my issue.
I have SITE1 ↔ SITE2 connected via IPSec tunnel
SITE1 192.168.1.0/24
SITE2 192.168.2.0/24
As you can see above IPSec tunnel works and rules added but the traffic not flows on it.
Can you please advise where to start the troubleshooting?
Should I add routes manually?
Looking forward your advise,
Thanks Tamas
This is just a guess but probably worth a try:
Your default masquerade rule in both sites has no src-address specified which leaves plenty of room for interpretation and I wouldn’t be surprised if tunnel traffic from the remote site gets masqueraded right away and comes out of your LAN-facing interface with your local router’s LAN address as source.
Try adding NAT accept rules for the other flow direction as well and probably add your local subnet as src-address for the masquerade rule.
In case you have you have a default route in place, there’s no need to manually add routes.
Good luck,
-Chris
Hi cdiedrich!
Thanks for your reply. I added them to NAT but no luck.
There is a default rule “accept” - “forward”. This can cause this anomaly? (I can not really make experiment to turn this rule-on/off" because these are production devices.
Did you adjust your masquerade rule as well?
And BTW, it’s better to post config exports than screenshots. A screenshot only shows a fraction of all possible parameters.
-Chris
Hi cdiedrich!
Can you please give me more instructions/insight about masquerade ?
What to set up at masq. rule? Dst / Src addresses?
Many thanks,
Tamas
Insight:
looking at your screenshot, your masquerade rule doesn’t have a matcher for src-address. It may happen (that’s still my guess, but it’s not unlikely) that traffic from the remote network gets caught by this rule and then gets masqueraded, leaving your router via pppoe-out1 (when I read your screenshots correctly)
instructions:
Add src-address to this rule (that would be 192.168.1.0/24 for site A and 192.168.2.0/24 for Site B) on both sites.
With this in place, traffic coming in from the other site will not be caught by this masq rule. Normally the accept rules above that will handle this…
Now typing this reply brings me to another idea:
Do you happen to have fasttrack enabled? In this case, we found the culprit.
You may try it with globally disabling fasttrack - looking at your hardware (1100AHx4), it should still be beefy enough for going on w/o fasttrack.
If not, have a look at this article describing the process of excluding IPsec tunnel traffic from fasttrack.
Good luck,
-Chris
Hi cdiedrich!
Thank you trying to help me in this nightmare…
Actually there was a fasttrack on the smaller device what I disabled earlier.
The truth will be somewhere there that the router not pushing the traffic into the tunnel.. it can be exactly seen on traceroute.
I added the router configs as well before I added the masq. rule to both device.. unfortunately nothing changed..
gemtech_giganet.rsc (5.93 KB)
gemtech_napkor.rsc (8.61 KB)
I think I found a typo in “giganet” router’s ipsec policy:
Its address should be 178.x.x.33 but in the policy sa-src-address is configured as 178.x.x.153
The rest is not looking too bad on first sight.
-Chris
Hi Chris!
I corrected it, I’ve no idea how it happened that the tunnel was established.
BTW I’ve made the changes.. but still no luck. Can it be the default forward rule causing this?
I have seen in your screenshots that you open 4500 UDP port, but I believe you are missing protocol 50 (IPSEC-ESP). That is used to transport de encrypted traffic once the tunnel is establish, so if you don’t allow it, the tunnel is established, but the data does not flow.
/ip firewall filter
add action=accept chain=input in-interface=ether1-wan protocol=ipsec-esp