OpenVPN TAP pfSense Gateway Website Inaccessible
-
Disclaimer: Well familiar with differences between TUN/TAP and do not need a primer on "hey, should you really be using TAP in the first place?"
I am running a site-to-site OpenVPN TAP mostly successful. Everything is working save for the fact that I cannot access the pfSense gateway webpage from opposite sides of the bridge (The server-side segment of the bridged LAN cannot access the client side's pfSense gateway website and vice versa). When i check in wireshark a SYN packet is sent out, but no acknowledgements. Other testing: Both gateways can ping each other directly as can clients ping gateways on both sides of the bridge. Only TCP based services (HTTP/HTTPS/SSH on pfSense) seem to be impacted.
Aside from this all aspects of an OpenVPN bridge configuration work. I've also reviewed much of the discussion in https://www.youtube.com/watch?v=ku-fNfJJV7w for additional insight. The TAP operates off of a standard bridge between the LAN interface on the gateway and the OpenVPN interface.
Any suggestions on how to alter my configuration to deal with this would be appreciated.
Other notes: LAN is a private subnet /24, DHCP packets are blocked on the OpenVPN interface so that each side of the bridge obtains leases locally. I've also tried configurations where a separate NIC is installed for the LANs and dedicated to the server and client to run the VPN. This solves the gateway web inaccessibility (as the interface/IP of the gateway is no longer participating in the bridge), but also causes 2-3% packet loss on average, so I suspect there's something problematic with that configuration I don't quite grasp yet.
// SERVER:
dev ovpns1
verb 4
dev-type tap
dev-node /dev/tap1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local [PUBLIC_IP]
engine cryptodev
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 2
secret /var/etc/openvpn/server1.secret
compress lz4-v2
fast-io
allow-recursive-routing// CLIENT:
dev ovpnc1
verb 1
dev-type tap
dev-node /dev/tap1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local [PUBLIC IP]
engine cryptodev
lport 0
management /var/etc/openvpn/client1.sock unix
remote [FQDN] 1194
secret /var/etc/openvpn/client1.secret
compress lz4-v2
resolv-retry infinite
fast-io
allow-recursive-routing -
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.
