pfSense mangling packets?
-
@stephenw10 another prime x-y problem example
-
@stephenw10 No DNS is going over pfsense but I've set cloudflare and google dns. But except that all other traffic is routed through vpn
-
@Tueem said in pfSense mangling packets?:
No DNS is going over pfsense
This can cause issues with stuff that is hosted in CDNs.. where you have one part of system pulling a dns from region X dns, and maybe the other end pulling from region Y.. And then for what your trying to do there ends of being a disconnect in who ends up talking to who up in the cloud, or talking from a different region that what is expected, etc.
-
Mmm, when you run the VPN client on the host I imagine it routes all traffic over the VPN and likely resets the host to se the VPN providers DNS. You should be able to check that on the host.
I would try setting the DNS on the server to the same thing the VPN clients sets it to and then policy route all traffic from it over the VPN.
-
@stephenw10 That didn't help unfortunately
-
What might also be interesting is that TLS handshakes with some sites (according to firefox) take very long through the vpn and cause a timeout.
-
@Tueem said in pfSense mangling packets?:
with some sites (according to firefox)
How does this info present itself? While I don't run normally through a vpn, I do now and then testing stuff.. Not some service my own vpn that I run on a vps out on the internet, etc. And have never seen any such info presented..
Long handshakes through a vpn would get me concerned about a mitm on the cert or some sort of proxy doing a bump on the ssl.. While sure a vpn can add some latency to the connection. There should be nothing really different in the handshake time other than whatever latency your seeing through the vpn for all traffic.
Can you post up screenshot of how firefox is presenting that little tidbit of info?
-
@johnpoz Its this pop-up in the bottom left I'm referring to:
-
Try opening the Firefox debug console and looking at the network connections/timing while doing that.
-
@stephenw10 Here is the entire log:
As you can see the result is missing css
-
It looks like you have a an adblocker and it's blocking the css file along with all the actual ads.
-
@stephenw10 hmmm thats weird. I'm gonna ask the VPN provider because I definitely don't have one
-
@stephenw10 I've asked the VPN provider and waiting for an answer but I don't think that will be the problem since im using google dns and the same issues happens if I use another Wireguard VPN. I'm guessing its some kind of wireguard problem
-
@Tueem
Do you have IPv6 enabled and working? -
@w0w no I don't
-
@Tueem I just confirmed, it's definitely not the VPNs fault. I booted up a quick instance of OpenWrt and there having my server routed through the VPN works fine.
-
@Tueem
Interesting. I have similar issues with the same addresses 13.x.x.x and pfSense when I use a specific PPPoE connection, but the problem only arises when I use IPv6, which I also obtain via DHCP. Interestingly, everything works fine without pfSense in the loop. There must be something in pfSense itself, and in my case, IPv6 is just the trigger. -
Hmm, but you're not actually using IPv6 to reach it? And also over Wireguard?
-
I just wanted to throw in, that OpenVPN also works fine so I'm 99% sure there is something wrong with the wireguard plugin.
-
@stephenw10
No wireguard in my case. Now I use PPPoE only for IPv4 and HE GIF for the IPv6 testing and fallback. No problem with 13.x.x.x based sites currently, but I did not tested all of them.
I honestly don't understand what the relation to IPv6 is at all if packet capture shows that the connection is going through the IPv4 stack. I would be sure that it's some configuration error either from the provider's side or somewhere else on my end, but in fact, everything works directly, without pfSense.
