VPN client fails behind the router

Installing and Using OpenWrt Network and Wireless Configuration
1

Tried using my VPN client (Barracuda) on a laptop connected to an OpenWRT router. I get a "Handshake Request Timeout" in the Barracuda VPN client when trying to connect.
Upon looking at tcpdump on the router itself:

router@OpenWRT:~# tcpdump -i usb0 -avvvn host vpn.xxx.xxx.srv
tcpdump: listening on usb0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:37:41.338449 IP (tos 0x0, ttl 63, id 35057, offset 0, flags [none], proto UDP (17), length 112)
openwrt.router.ip.addr.65063 > vpn.xxx.xxx.srv.691: [udp sum ok] UDP, length 84
19:37:41.395273 IP (tos 0x0, ttl 52, id 60320, offset 0, flags [none], proto UDP (17), length 1428)
vpn.xxx.xxx.srv.691 > openwrt.router.ip.addr.65063: [udp sum ok] UDP, length 1400
19:37:43.793222 IP (tos 0x0, ttl 52, id 20933, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:37:43.861090 IP (tos 0x0, ttl 52, id 25541, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:37:45.524296 IP (tos 0x0, ttl 52, id 58310, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:37:47.517554 IP (tos 0x0, ttl 52, id 34760, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:37:49.531520 IP (tos 0x0, ttl 52, id 52937, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:37:51.519627 IP (tos 0x0, ttl 52, id 29130, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:37:53.582866 IP (tos 0x0, ttl 52, id 30668, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:37:55.540372 IP (tos 0x0, ttl 52, id 16847, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:37:57.543779 IP (tos 0x0, ttl 52, id 1489, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:37:59.532714 IP (tos 0x0, ttl 52, id 44242, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:38:01.529980 IP (tos 0x0, ttl 52, id 33235, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:38:03.529405 IP (tos 0x0, ttl 52, id 59859, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:38:05.591956 IP (tos 0x0, ttl 52, id 46549, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:38:07.548529 IP (tos 0x0, ttl 52, id 62423, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:38:09.579085 IP (tos 0x0, ttl 52, id 56537, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17
19:38:11.541198 IP (tos 0x0, ttl 52, id 11482, offset 1440, flags [none], proto UDP (17), length 629)
vpn.xxx.xxx.srv > openwrt.router.ip.addr: ip-proto-17

And here is a wireshark capture of the connection failing (VPN server IP is masked with red boxes):

image
image1290×327 95.4 KB

In contrast, here is the Wireshark capture of a successful connection over WiFi phone tethering:

image
image1191×816 251 KB

It looks like the packets from the VPN server are not properly forwarded back to the laptop connected on the LAN side. The VPN server is responding according to tcpdump on the device, but the laptop is not seeing those packets according to Wireshark captures. So they seem to be not forwarded properly.

Firewall settings are basically as below:

image
image986×741 38.9 KB

(except that Input on the WAN zone is also Accept in my case)

Everything else seems to work just fine (e.g. browsing, messengers, etc.).

Is there a firewall settings that can be adjusted to make sure this works?

2

Which are pretty bad for an internet connection.
Revert them to how they were. Delete the wan->lan forwarding. Wan forward to reject.
In general settings change the forward to reject.
Is the vpn based on pptp?

2 Likes
3

Thank you @trendy

Yeah, the zone forward settings will be adjusted but for troubleshooting purposes I'll leave as much open as possible.

I am not sure of the VPN type, but I'm certain it is not PPTP. Must be IPsec, I'll check with the sysadmin.

The most interesting find today was that the VPN client actually WORKS and CONNECTS if I change the Tunnel Mode to TCP instead of UDP in the Barracuda VPN client configuration. Really confused at this point. :roll_eyes: Could that be an issue with netfilter/kernel properly processing UDP packets? Any direction of what I could look at next will be highly appreciated.

4

I am not aware of such a behavior. Normally all packets must be treated the same. If you switch back to UDP does it still misbehave?

5

Thanks @trendy
Yeah, if I try UDP Tunnel Mode in the laptop's Barracuda VPN client, it fails (initial screenshots/pcaps). Barracuda VPN client also features Hybrid (UDP/TCP) mode, and that works only to establish the tunnel (I get routes/etc) but actual data is not flowing (e.g. browsing to local resources behind VPN is not available - times out).

6

Try decreasing MTU on the VPN interface.

See also: Torrents causing conntrack table to overflow

1 Like
7

Thank you @vgaetera
I decreased /dev/tun0 in use by the Barracuda VPN client to some ridiculously small value like 1260 but still in UDP mode the connection does not get established.

The issue must be with the router and I wonder what other suggestions you could give me where else to look and what to inspect. Appreciate any advice

8

Hi!
Any updates? I have the same problem when I am behind an edgeRouter. Everything works fine with tcp but I get a timeout while using UDP. If I have a public v4 or a v6 address everything works fine.
Interesting...

9

Is this ER running OpenWrt or EdgeOS? If you're running EdgeOS, the root cause may or may not be the same as what was causing issues for the OP (although maybe the info could be useful at a high level). If you are using EdgeOS, you should ask on the UI forums where you'll have an audience who may have encountered (and hopefully resolved) this issue on that platform.