OpenVPN TAP pfSense Gateway Website Inaccessible
-
Bump - any thoughts?
-
@seejay bump v2
-
bump v3
-
I must smell funny. a week goes by and no one wants to stop in and say hello on this thread.
-
Also has a TAP question in here, I must smell funny too because No replies
. I was though nowhere as detailed as you here, so maybe that explains the lack of response in my case.Have you tried manipulating MTU size?
I have a bit of limited network experience at just this scenario, as I struggle myself to get a simple Server-Client (Windows 10) bridge work as intended.
But to me this case could be about fragmentation I believe. -
@iorx said in OpenVPN TAP pfSense Gateway Website Inaccessible:
Have you tried manipulating MTU size?
II suspect you're not getting responses as most (all?) people use TUN mode.
BTW, if you use TAP, your MTU must be the same on the tunnel and both LANs.
-
@iorx Default MTUs are set on all interface cards at both pfsense gateways, so there should be no mismatch and the default 1500 should be getting used.
-
I will occasionally bump this in the hopes either an insight is shared or I figure it out first.
-
@seejay said in OpenVPN TAP pfSense Gateway Website Inaccessible:
Default MTUs are set on all interface cards at both pfsense gateways, so there should be no mismatch and the default 1500 should be getting used.
If your WAN connection has a 1500 byte MTU, your OpenVPN MTU will be 1472, due to 28 bytes lost to headers.
-
@JKnott Thanks. Are you suggesting I need to manually set MTUs on the WAN / LAN / OpenVPN interfaces and that defaults would cause this type of condition? If I set 1500 manually on the WAN, do I set 1472 on the OpenVPN adapter? What about the bridged LAN adapter?
-
I also see this entry from initialization, maybe the MTU config getting set?
/usr/local/sbin/ovpn-linkup ovpnc1 1500 1605 init
-
Confirmed with ping -n 1 -l 1472 -f [router ip] the max MTU
-
set WAN, LAN, and OPENVPN adapter in interface config all to 1500 on both sides of the tunnel. No impact.
-
Still see this in OpenVPN logs:
Nov 28 09:43:48 openvpn 23207 Local Options String (VER=V4): 'V4,dev-type tap,link-mtu 1605,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA256,keysize 256,secret'
Doesn't seem right.
-
@seejay said in OpenVPN TAP pfSense Gateway Website Inaccessible:
@JKnott Thanks. Are you suggesting I need to manually set MTUs on the WAN / LAN / OpenVPN interfaces and that defaults would cause this type of condition? If I set 1500 manually on the WAN, do I set 1472 on the OpenVPN adapter? What about the bridged LAN adapter?
If your WAN is 1500, the VPN will be 1472. If the LAN at either end is other than 1472, then you will have an issue with handling packets that have the full MTU. A TAP VPN is functionally the same as a bridge or switch, in that all connected networks must support the same MTU. With IP, the 2 end points negotiate the MTU, based on the end with the smallest MTU. The VPN MTU will not be considered in that process. If it was a TUN VPN, then the smaller MTU will cause the router to fragment the packet or send a too large ICMP message back to the source. That cannot happen with a TAP VPN, so there is no mechanism to reduce the MTU.
Bottom line, the WAN MTU determines the VPN MTU, which in turn determines the LAN MTUs.
-
@JKnott So if I force both WANs to 1500 MTU, and both LANS to 1472 MTU, do I need to apply an mssfix or other value to the openvpn config or will it determine it correctly? I separately dont understand how when setting WAN1500, LAN1472, OpenVPN server reports on startup:
Nov 28 10:04:51 openvpn 82520 Local Options String (VER=V4): 'V4,dev-type tap,link-mtu 1605,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA256,keysize 256,secret'
Nov 28 10:04:51 openvpn 82520 Expected Remote Options String (VER=V4): 'V4,dev-type tap,link-mtu 1605,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA256,keysize 256,secret'
Lastly, I would expect this problem only to occur on packets large enough in size to approach this boundary. The website packets for the gateway that fail are usually no greater than a couple 100.
-
A quick LAN speed test across the VPN shows better read performance undoubtedly forcing WAN at both ends to 1500, LAN at both ends to 1472, and mssfix on both OpenVPN configs to 1432. sadly, the respective pfsense websites at opposite ends of the bridge still are not coming up (but still ping).
-
Taking the MTU advice I applied it back to our dedicated NIC configuration (Separate set of NICs on the pfsense boxes attached to the same LAN but with no IP assigned in pfsense). Seems to be stable so far with no dropouts, and I can again reach the pfsense websites across the bridge. Going to run this way for a bit and see if we stay stable with 0% packet loss.
-
@seejay said in OpenVPN TAP pfSense Gateway Website Inaccessible:
So if I force both WANs to 1500 MTU, and both LANS to 1472 MTU, do I need to apply an mssfix or other value to the openvpn config or will it determine it correctly
It should be OK, as there will not be a conflict with MTU size.
-
Back to square zero. Separate dedicated NICs with no IP observe packet loss and instability, using same LAN nic as PFSENSE LAN IP assignment makes everything stable but cant access web pages across the bridge. MTUs set properly now in both cases.
