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

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    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

  • Well, I turned off geolocation but it didn’t help. Everything works fine from the location of T70 BTW
    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.

  • Yes, all traffic from Mikrotik goes through BOVPN
    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

  • edited January 20
    I sorted out outgoing policy and routed traffic through http and https proxies policies. However still some sites cannot be opened. This is what I get trying to connect to Yandex.ru
    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 :

    /ip firewall mangle
    add action=change-mss chain=forward new-mss=1382 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=!0-1382
    

    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

  • edited January 22

    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.

  • Hi, I sorted the thing out. I haven’t add Dynamic NAT for network segments I receive from remote location. Also Bruce_Briggs solution works with sites that I could not open earlier. Unfortunately MWhiteley solution doesn’t work but thank you very much for the explanation. Very helpful!
    Cheers
  • edited January 23

    So you had deleted/modified one or more of the 3 default Dynamic NAT entries for the 3 private subnets on your WG firewall ????

  • edited January 23
    I am not sure about default Dynamic Nat entries. I do not seem to have anything default there. I guess as soon as i use 0.0.0.0/0 for traffic and did not create any IP for VPN traffic in WG i had to add entries to Network>NAT>Dynamic NAT like REMOTE_IP_ADDRESS>External. Since i added it everything goes fine.
  • 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.

  • Well, I have all three now and have no idea why some of them gone. Thank you! BTW WG support never found their absence examining my config.
Sign In to comment.