Really Strange VPN Problem

RouterOS General
1

Hello guys,
I am experiencing a weird problem with my vpn setup on a RB3011.

At the moment I am using a PPTP Site-to-Site and PPTP/L2TP Road Warrior setups.
The biggest problem which is the site to site pptp stopped working after upgrading from 6.32 to 6.38

Now the weird stuff.

  • Site to site PPTP with a tomato Router: Tunnel active, can ping hosts, can’t access anything (e.g. winbox connects, can’t see any contents)
  • L2TP Road warrior: Windows Clients successfully connect, can ping hosts, can’t access anything like above
  • L2TP Road warrior: iOS clients successfully connect, can access all resources.
  • PPTP Road warrior: Windows clients successfully connect, can access all resources.

I can’t understand where is the problem.

/interface print 
Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                                TYPE       ACTUAL-MTU L2MTU  MAX-L2MTU
 0  R  WAN                                 ether            1500  1598       8156
 1  RS ether2-master-local                 ether            1500  1598       8156
 2  RS ;;; Building B
       ether3-slave-local                  ether            1500  1598       8156
 3   S ether4-slave-local                  ether            1500  1598       8156
 4   S ether5-slave-local                  ether            1500  1598       8156
 5  RS ether6-master-local                 ether            1500  1598       8156
 6  RS ether7-slave-local                  ether            1500  1598       8156
 7   S ether8-slave-local                  ether            1500  1598       8156
 8   S ether9-slave-local                  ether            1500  1598       8156
 9   S ether10-slave-local                 ether            1500  1598       8156
10  RS ;;; Unifi Switch8-150
       sfp1                                ether            1500  1600       8158
11 DR  <l2tp-vaiosmob>                     l2tp-in          1450
12 DR  <pptp-larisa1>                      pptp-in          1450
13 DR  <pptp-vaios>                        pptp-in          1400
14  R  ;;; Guest VLAN
       Guest-VLAN                          vlan             1500  1594
15  R  bridge-local                        bridge           1500  1598
16  R  pppoe-out1                          pppoe-out        1480




/ip address print
Flags: X - disabled, I - invalid, D - dynamic 
 #   ADDRESS            NETWORK         INTERFACE                                              
 0   ;;; Default LAN
     192.168.16.1/24    192.168.16.0    ether2-master-local                                    
 1   ;;; Guest VLAN
     192.168.216.1/24   192.168.216.0   Guest-VLAN                                             
 2   ;;; Access ADSL Modem
     192.168.2.252/24   192.168.2.0     WAN                                                    
 3 D XX.XX.XX.XX/32    XX.XX.XX.XX     pppoe-out1                                             
 4 D 192.168.16.1/32    192.168.16.218  <pptp-larisa1>                                         
 5 D 192.168.188.224/32 192.168.188.1   pptp-atrium                                            
 6 D 192.168.16.1/32    192.168.16.215  <pptp-vaios>                                           
 7 D 192.168.16.1/32    192.168.16.214  <l2tp-vaiosmob>




/ip pool print
 # NAME                                                         RANGES                         
 0 mgmt_pool                                                    192.168.16.100-192.168.16.200  
 1 guests_pool                                                  192.168.216.122-192.168.216.249
 2 vpn_pool                                                    192.168.16.208/28




/ppp profile print
Flags: * - default 
 0 * name="default" local-address=192.168.16.1 remote-address=vpn_pool 
     remote-ipv6-prefix-pool=*0 bridge=bridge-local use-ipv6=no use-mpls=default 
     use-compression=default use-encryption=yes only-one=default change-tcp-mss=yes 
     use-upnp=default address-list="" on-up="" on-down="" 

 1   name="pptp-profile" local-address=192.168.89.1 remote-address=vpn_pool 
     remote-ipv6-prefix-pool=*0 use-ipv6=no use-mpls=default use-compression=default 
     use-encryption=required only-one=default change-tcp-mss=default use-upnp=default 
     address-list="" on-up="" on-down="" 

 2   name="OVPN_profile" local-address=10.9.9.50 remote-address=10.9.9.51 
     remote-ipv6-prefix-pool=*0 use-ipv6=yes use-mpls=default use-compression=default 
     use-encryption=default only-one=default change-tcp-mss=default use-upnp=default 
     address-list="" on-up="" on-down="" 

 3 * name="default-encryption" local-address=192.168.16.1 remote-address=vpn_pool 
     remote-ipv6-prefix-pool=*0 bridge=bridge-local use-ipv6=no use-mpls=default 
     use-compression=default use-encryption=required only-one=default change-tcp-mss=yes 
     use-upnp=default address-list="" dns-server=192.168.16.1 on-up="" on-down=""




/interface pptp-server server print
            enabled: yes
            max-mtu: 1450
            max-mru: 1450
               mrru: disabled
     authentication: mschap1,mschap2
  keepalive-timeout: 30
    default-profile: default-encryption




/interface l2tp-server server print
            enabled: yes
            max-mtu: 1450
            max-mru: 1450
               mrru: disabled
     authentication: mschap2
  keepalive-timeout: 30
       max-sessions: unlimited
    default-profile: default-encryption
          use-ipsec: yes
       ipsec-secret: xxxxxxxxxxxxxxxxxx
    allow-fast-path: no




/ip route print
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADS  0.0.0.0/0                          62.38.0.170               0
 1 ADC  XX.XX.XX.XX/32     XX.XX.XX.XX    pppoe-out1                0
 2   S  192.168.1.0/24                     192.168.89.212            1
 3 ADC  192.168.2.0/24     192.168.2.252   WAN                       0
 4 A S  192.168.9.0/24                     192.168.188.1             1
 5 A S  192.168.14.0/24                    192.168.188.1             1
 6 ADC  192.168.16.0/24    192.168.16.1    bridge-local              0
 7 ADC  192.168.16.214/32  192.168.16.1    <l2tp-vaiosmob>           0
 8 ADC  192.168.16.215/32  192.168.16.1    <pptp-vaios>              0
 9 ADC  192.168.16.218/32  192.168.16.1    <pptp-larisa1>            0
10 ADC  192.168.188.1/32   192.168.188.224 pptp-atrium               0
11 ADC  192.168.216.0/24   192.168.216.1   Guest-VLAN                0

Please let me know if you need me to attach more config details

2

For example this is what I get when I log into winbox from a host in Tomato router domain (PPTP Site-To-Site). The winbox session disconnects after around 1 minute
Putty ssh connection and configuration works.
Untitled.jpg

3

Hello, it looks like a MTU or TCP-MSS problem, try to change those values and try again

4

That is really strange.
Site to site PPTP uses MTU: 1450 and MRU: 1450 - DOESNT WORK
Windows L2TP uses MTU: 1400 and MRU: 1450 - DOESNT WORK
iOS L2TP uses MTU: 1450, MRU: 1450 - WORKS
Windows PPTP uses MTU: 1400 and MRU 1450 - WORKS

5

I can confirm that I am seeing a similar problem to what you report when using PPTP between MikroTik routers running either 6.37.5 or 6.38.5 firmware. However, I have some further insights due to having had to debug a very esoteric problem with EoIP tunnels.

Here is what I believe is happening. Applications running on RouterOS, like WebFig or WinBox, will submit outgoing packets to the network interface that are as large as they need to be to send the entire data exchange. For example, when running WinBox, the RouterOS system that the WinBox client is connected to will typically send two different size packets when just updating the client without any other activity. To illustrate, with one packet capture I observed on the sending RouterOS system, I was seeing a combination of packets of 8+ kB and 13+ kB that repeat continuously to update the WinBox display. Obviously, these packets will get fragmented by the network interface, and the WinBox client will see these large packets broken into a set of smaller packets that are equal to the MTU of the intevening network (typically, 1.5 kB).

However, when using PPTP tunnels in the more recent versions of RouterOS, the tunnels do not appear to be correctly performing the packet fragmentation before sending the data over the wire (physical wire or virtual wire). Consequently, the WinBox (or WebFib browser) client is not receiving a lot of the data sent. This is why you’re seeing the empty windows with your WinBox client, and why the connection terminates after about 30 to 60 seconds. You can use the ping tool to confirm that there is a problem with large packets sent via the PPTP interface. If large packets do get through, then they are unreliable with many lost.

When accessing the router over a PPTP tunnel using a browser, there is a similar problem, and the WebFig session will not come up correctly. However, SSH tends to send data in smaller packets, and so it will often work, though if you push a lot of data through an SSH session (e.g., perform an export of a large config), then SSH may also hang up or lose data.

In my testing so far, IPIP tunnels do not have this problem, and one set of tests indicates that IPsec tunnels also work correctly. However, there is definitely a problem with PPTP tunnels. I’ve also been playing around with MTU, MRU and MRRU settings on the PPTP server and client configs, and while this has an affect on the problem, I have not found a magic combination that works reliably. Since I have been upgrading a working configuration, I can also confirm that this problem appears to have been introduced in the 6.37 and 6.38 versions.

6

The strange fact about this situation is that for example L2TP over IPsec works flawlessly on iOS clients while on Windows it doesn’t while using the same Secrets and profile.

And on the same idea, roadwarrior pptp works from windows machines while it does not as site to site

It is really weird.

7

This is my problem too - it works flawlessly on a Mac (L2TP over IPSec - then connect to winbox for remote router), but on windows it drops after 30 seconds or so.

8

When it is an MSS problem it may be that ICMP packets to indicate too large segments are incorrectly sent or processed.
This is always problematic with VPN tunnels. The source address of the ICMP may be strange or it may be sent outside
of the tunnel and the other side may not “relay” it to the connection to the client.

It is unfortunate that modern OSes send everything with DF set because that way they shoot themselves in the foot.
(without the DF the router would fragment the packet, which would be less efficient but it would still work, instead of causing a stuck connection)

For TCP you can work around this problem by adding this rule to the router:

/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu protocol=tcp \
    tcp-flags=syn

For UDP and other protocols that of course does nothing.