BOVPN open only some sites
Hi
We set up BOVPN between 2 locations using Microtik and XTM70. Everything works fine except some sites refuse to open. Most of .com sites work fine, my most of .ru sites just stuck. Any ideas where to look?
Thanks
We set up BOVPN between 2 locations using Microtik and XTM70. Everything works fine except some sites refuse to open. Most of .com sites work fine, my most of .ru sites just stuck. Any ideas where to look?
Thanks
0
Sign In to comment.
Comments
Hi @Pythagor
Are you using geolocation?
(Geolocation)
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/geo/geo_config_c.html
If Russia is set to blocked, it'll likely be getting most of the .ru top level domain sites.
A site to site VPN generally won't change internet bound traffic unless the VPN is set up with a default (zero) route.
-James Carson
WatchGuard Customer Support
Thanks
Is this BOVPN set up so that all traffic from the Microtik goes to the the T70, including Internet traffic (a default/zero route BOVPN)?
If so, anything in your T70 Traffic Monitor related to access from the Microtik end ?
For debugging purposed, you can turn on Logging on the policy which allows BOVPN access from the Microtik, to see packets allowed bu it in Traffic Monitor.
I do not see any deny messages. Traceroute shows complete path to destination site. Interesting, that I cannot find a rule in WG to allow any traffic from BOVPN but traffic still flows.
Do you have an Outgoing policy in your config?
What is on the From: field?
Look for policies with From: = Any
https://share.icloud.com/photos/0UIXKbcTrVJ0qvHyGqQ5MRoNA
Some web sites don't seem to work well via a BOVPN or via some other access which reduces the data packets size below some critical size.
One option is to enable PMTU checking in the PC which is attempting to access the remote web site.
See my post here on how to do this. Also look at my post just above it.
https://community.watchguard.com/watchguard-community/discussion/comment/5280#Comment_5280
Sometimes setting the external interface Advanced Setting or BOVPN setting for the DF bit to clear helps.
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/define_gateway_endpts_c.html
Pretty much as Bruce_Briggs says! There is an easier fix for the Mikrotiks though
TLDR :
Use the clamp MSS function on the Mikrotik to fix this with something like :
Note that is a generic command and you will most likely want to put some further filtering in there so it doesn't act on ALL traffic. However if your setup is simple, this will probably fix it.
Problem
Packets with the DoNoFragment bit set get silently dropped and so certificate exchange and other MTU sensitive operations fail.
Cause
Most internet devices assume a 1500 MTU and begin to transmit at this size. If a router in the middle has an MTU of 1480 then it will fragment packets (1480 + another 20 (plus IP headers etc.)). Not a problem other than it's inefficient. Some exchanges (certificates etc.) though specify that they want the entire packet to arrive intact and so set the DoNotFragment bit in the TCP header. This is ok, the router with the 1480 MTU sends back an ICMP message saying "DoNotFragment bit is sent however fragmentation is required", at which point the sending end does some path MTU discovery and figures out it needs to send at an MTU of 1480.
The problem comes when it's a layer 2 transport in the middle that has a lower MTU. That is, if a router has an interface MTU of 1480 then that's OK, it's a layer 3 router and it can send back ICMP messages. If a Switch has an MTU of 1480 but the routers either side have 1500 then you have a problem, the switch is not a 'hop' along the routing path and so it drops the packet that is too large and has no means to communicate that to anyone.
The same is true of IPSec encapsulation, the Mikrotik (and most routers) is using what is effectively a layer 2 tunnel to get your data across the WAN. This tunnel has IP header overhead and so does not have an MTU of 1500, it is also not a hop along the path (the routers either end are but their MTUs are 1500 if you look at their interfaces). So again you get silently dropped packets where the DNF bit is set.
Solution 1
Do NOT block ICMP - some people do this for stealth reasons however you will also block all those ICMP control messages that say "DoNotFragment bit is sent however fragmentation is required"
Solution 2
You need to alter the packets that travel through the router's IPSEC tunnel and clamp the MSS option within the TCP header (MSS + Headers = MTU).
Doing it at the firewall level means you don't have to worry about the endpoints. Here is an example where your local subnet is 192.168.20.0/24 and that is going across the IPSec to the head office :
/ip firewall mangle
add action=change-mss chain=forward new-mss=1382 passthrough=yes protocol=tcp src-address-list=192.168.20.0/24 tcp-flags=syn tcp-mss=!0-1382
Hi. Thank you for advices! Unfortunately I cannot now connect to any site regardless I can see all traffic allowed in Traffic monitor. It looks like it goes out but not coming back
No changes made on either end?
I added rule to allow any BOVPN traffic to any and reconfigured MikroTik from scratch. I can ping sites but cannot open web pages
I would look at the reconfigured MikroTik first
I can open any sites before firebox on remote location. It doesn’t look like MikroTik problem.
Do you have the old MikroTik config saved that you could reload and test web site access with it?
Did you make any changes on the Advanced Tab of the XTM 70 rule to allow any BOVPN traffic to any, such as unselecting the Dynamic NAT check box ?
Try disabling the new XTM 70 rule and see if that makes the web access work.
I didn’t change default settings. Killing these ANY rules doesn’t do anything. I put them as first rules now and this also doesn’t help. I will locate microtik configuration with initial problem an try it.
Cheers
So you had deleted/modified one or more of the 3 default Dynamic NAT entries for the 3 private subnets on your WG firewall ????
The 3 default Dynamic NAT settings in Fireware are:
192.168.0.0/16 - Any-external
172.16.0.0/12 - Any-external
10.0.0.0/8 - Any-external
They should be in any config until modified or deleted.
Thank you MWhiteley, solution for me
/ip firewall mangle
add action=change-mss chain=forward new-mss=1382 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=!0-1382