Page 1 of 1
Some web pages don't load
Posted: Tue Oct 11, 2022 9:47 pm
by remre
Some load but partially and lack content. Some load in a way that the browser doesn't consider them secure.
Ping is ok.
DNS is ok.
Firewall shows nothing specific to the problem.
The problem occurs only when using the vpn. Without the vpn, there's no problem.
In the logs of the server, there's some
PID_ERR replay-window backtrack occurred and a lot of
MULTI: bad source address from client.
I read a lot about the
bad source address from client error and it doesn't make sense to me : it is the IP address of the openvpn client but not the one of the virtual interface associated with the vpn but enp0s3 with the address leased by my local router. Why would some packets end up in the server going through the tun device and the server would see the enp0s3 interface's address ?
I suspected finally a bad integration between NetworkManager and openvpn but it's been working great for almost two years now. Yet I read that importing the configuration via nmcli may eliminate some bug so I did it but to no avail.
It is somehow unusable now...
It's an up to date Debian 11 with Xcfe as desktop environment.
Anyone any idea what's going on and what I should do to diagnostic correctly and fix it ?
Server and client configurations :
Code: Select all
port 1194
proto udp
dev tun
ca ca.crt
cert openvpn_server.crt
dh dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.8.0.1"
duplicate-cn
keepalive 10 120
tls-crypt ta.key
auth SHA512
tls-version-min 1.3
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
max-clients 3
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 4
explicit-exit-notify 1
auth-nocache
chroot /etc/openvpn/jail
and
Code: Select all
client
tls-client
dev tun
proto udp
remote x.x.x 1194 udp4
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
remote-cert-tls server
auth SHA512
user nobody
group nogroup
script-security 2
dhcp-option DNS 10.8.0.1
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
verb 5
explicit-exit-notify 2
--auth-nocache
Re: Some web pages don't load
Posted: Tue Oct 11, 2022 11:24 pm
by TinCanTech
Do you know which crucial detail you omitted ?
Re: Some web pages don't load
Posted: Wed Oct 12, 2022 6:06 am
by remre
What's your insight ?
Re: Some web pages don't load
Posted: Wed Oct 12, 2022 11:16 am
by TinCanTech
Your DNS is probably the problem.
Re: Some web pages don't load
Posted: Wed Oct 12, 2022 12:36 pm
by remre
What if not ?
Code: Select all
dig +trace google.fr
; <<>> DiG 9.16.33-Debian <<>> +trace google.fr
;; global options: +cmd
. 86400 IN NS h.root-servers.net.
. 86400 IN NS i.root-servers.net.
. 86400 IN NS j.root-servers.net.
. 86400 IN NS k.root-servers.net.
. 86400 IN NS l.root-servers.net.
. 86400 IN NS m.root-servers.net.
. 86400 IN NS a.root-servers.net.
. 86400 IN NS b.root-servers.net.
. 86400 IN NS c.root-servers.net.
. 86400 IN NS d.root-servers.net.
. 86400 IN NS e.root-servers.net.
. 86400 IN NS f.root-servers.net.
. 86400 IN NS g.root-servers.net.
. 86400 IN RRSIG NS 8 0 518400 20221025050000 20221012040000 18733 . CGxKLsqLS4MGlLkB8XFDtcE2zsfSJHiz7q0U6ACFll9Nt0q5lGVHO+Gh 3jRkdBfd5F6LdP1p4jquEh92yx5UgKoZBPs+d9xbvISJOQ7288eQWu5F TrL79rby5nmCl8qMeSR+LEM2V4+OHd7FOFWhPwTlp4tN0WWP25ZCMMLn Se0HHCnhUNxjHSqNtt7G1odyIa5xeLMkXUBC65cC2wYpHRba15Byy1xr 6vNxYBBjE0Xfj/i10bxdw0/r3gxZSi2NiJbLD+8zJEiHai28zXLFt2ht o5GpHnpMNtzoXl5EdkMAoUoe3mmB5vUtDdDGT5ZG5aaarKhrtxZzllvU NwDW6Q==
;; Received 525 bytes from 10.8.0.1#53(10.8.0.1) in 96 ms
fr. 172800 IN NS d.nic.fr.
fr. 172800 IN NS e.ext.nic.fr.
fr. 172800 IN NS f.ext.nic.fr.
fr. 172800 IN NS g.ext.nic.fr.
fr. 86400 IN DS 51508 13 2 1B3386864D30CCC8F4541B985BF2CA320E4F52C57C53353F6D29C9AD 58A5671F
fr. 86400 IN RRSIG DS 8 1 86400 20221025050000 20221012040000 18733 . t1QO2mC/EpuX1bIzBPYUXuMxLBZI5fwuWdWDnvrxc7/XxEDOg+oK1Oin /mZiLiElMw5X+szOjqNi7oQktUvGklfgbZQMZf4PzUAlywgg1M7BR1Vw A+WfnPHQvvXkGjt3XORVRgoDHVYTi7pD7fG2ZL7MaV5+p3MpCozSUO7p wMGwbaamMUePAnpy7QsTaWRWi/S/k8QSQ4rYrt0Nh7rEjSjtSz0OstJs tRD3wmZVrox9QOcUpgmVqrJovo9aO5ZHIFrb5Tvmqh3uwZI6Bnx2wx49 o5qUOVSLRlnvMQny3L//LgrhOQo7MFfG8+s7zZw4XJmTARmvjzwMVbcr yMWoKw==
;; Received 621 bytes from 193.0.14.129#53(k.root-servers.net) in 80 ms
google.fr. 172800 IN NS ns3.google.com.
google.fr. 172800 IN NS ns1.google.com.
google.fr. 172800 IN NS ns2.google.com.
google.fr. 172800 IN NS ns4.google.com.
HSE6LVEAKJI7RI5C4E8A03BFG5HA71AO.fr. 5400 IN NSEC3 1 1 1 297E821C HSE6PKPOMG50JK2DK02DRF66LR6OOQFN NS SOA TXT NAPTR RRSIG DNSKEY NSEC3PARAM
HSE6LVEAKJI7RI5C4E8A03BFG5HA71AO.fr. 5400 IN RRSIG NSEC3 13 2 5400 20221206040203 20221001162327 1929 fr. SpXw2wJoKJ/bIsLcxMR54iD9cZD2Ii1QWcMczSqNXZ2NRddFBMWEDJ9o lW+Zo6myHY98DLKxsHFF0oIkH3KTIQ==
NUQM6BHA617F223OGI57QSDSPHKKTOLD.fr. 5400 IN NSEC3 1 1 1 297E821C NUQS9VB4JPK2S9R41HUQ11818T26M0D8 NS DS RRSIG
NUQM6BHA617F223OGI57QSDSPHKKTOLD.fr. 5400 IN RRSIG NSEC3 13 2 5400 20221112000055 20220912233529 1929 fr. ddv7Fr70sBQ/xaOSAMLgiJdkdN3i/pDhq7oW763S9J/1p2E0e1VwxlGQ xJYhLKHa7MSEAUR+4M0YyRRm7eJUaw==
;; Received 511 bytes from 194.0.9.1#53(d.nic.fr) in 72 ms
google.fr. 300 IN A 216.58.214.163
;; Received 54 bytes from 216.239.32.10#53(ns1.google.com) in 60 ms
Client side DNS query's trace through vpn successful.
Code: Select all
Starts at 13:48:03 querying DNS root server
...
Oct 12 13:48:03 vps0 unbound: [97421:0] info: response for ns1.google.com. A IN
Oct 12 13:48:03 vps0 unbound: [97421:0] info: reply from <google.com.> 2001:4860:4802:34::a#53
Oct 12 13:48:03 vps0 unbound: [97421:0] info: query response was ANSWER
Oct 12 13:48:03 vps0 unbound: [97421:0] info: response for ns1.google.com. AAAA IN
Oct 12 13:48:03 vps0 unbound: [97421:0] info: reply from <google.com.> 216.239.34.10#53
Oct 12 13:48:03 vps0 unbound: [97421:0] info: query response was ANSWER
Oct 12 13:48:03 vps0 unbound: [97421:0] info: response for ns1.google.com. AAAA IN
Oct 12 13:48:03 vps0 unbound: [97421:0] info: reply from <google.com.> 216.239.38.10#53
Oct 12 13:48:03 vps0 unbound: [97421:0] info: query response was ANSWER
Oct 12 13:48:03 vps0 unbound: [97421:0] info: resolving ns2.google.com. A IN
Oct 12 13:48:03 vps0 unbound: [97421:0] info: resolving ns2.google.com. AAAA IN
Oct 12 13:48:03 vps0 unbound: [97421:0] info: response for ns2.google.com. A IN
Oct 12 13:48:03 vps0 unbound: [97421:0] info: reply from <google.com.> 2001:4860:4802:38::a#53
Oct 12 13:48:03 vps0 unbound: [97421:0] info: query response was ANSWER
Oct 12 13:48:03 vps0 unbound: [97421:0] info: response for ns2.google.com. AAAA IN
Oct 12 13:48:03 vps0 unbound: [97421:0] info: reply from <google.com.> 216.239.38.10#53
Oct 12 13:48:03 vps0 unbound: [97421:0] info: query response was ANSWER
Oct 12 13:48:03 vps0 unbound: [97421:0] info: response for ns2.google.com. AAAA IN
Oct 12 13:48:03 vps0 unbound: [97421:0] info: reply from <google.com.> 2001:4860:4802:38::a#53
Oct 12 13:48:03 vps0 unbound: [97421:0] info: query response was ANSWER
Oct 12 13:48:04 vps0 unbound: [97421:0] info: resolving ns4.google.com. A IN
Oct 12 13:48:04 vps0 unbound: [97421:0] info: resolving ns4.google.com. AAAA IN
Oct 12 13:48:04 vps0 unbound: [97421:0] info: response for ns4.google.com. A IN
Oct 12 13:48:04 vps0 unbound: [97421:0] info: reply from <google.com.> 216.239.38.10#53
Oct 12 13:48:04 vps0 unbound: [97421:0] info: query response was ANSWER
Oct 12 13:48:04 vps0 unbound: [97421:0] info: NSEC3s for the referral proved no DS.
Oct 12 13:48:04 vps0 unbound: [97421:0] info: Verified that unsigned response is INSECURE
Oct 12 13:48:04 vps0 unbound: [97421:0] info: response for ns4.google.com. AAAA IN
Oct 12 13:48:04 vps0 unbound: [97421:0] info: reply from <google.com.> 2001:4860:4802:32::a#53
Oct 12 13:48:04 vps0 unbound: [97421:0] info: query response was ANSWER
Oct 12 13:48:04 vps0 unbound: [97421:0] info: response for ns4.google.com. AAAA IN
Oct 12 13:48:04 vps0 unbound: [97421:0] info: reply from <google.com.> 2001:4860:4802:34::a#53
Oct 12 13:48:04 vps0 unbound: [97421:0] info: query response was ANSWER
VPN side DNS queries successful from dns server's logs where there's no error, warming or else.
And still some packets dropped by the VPN from openvpn server's logs :
Oct 12 13:48:03 vps0 openvpn[106793]: x:12384 MULTI: bad source address from client [10.58.140.49], packet dropped
Oct 12 13:48:03 vps0 openvpn[106793]: x:12384 MULTI: bad source address from client [10.58.140.49], packet dropped
Oct 12 13:48:03 vps0 openvpn[106793]: x:12384 MULTI: bad source address from client [10.58.140.49], packet dropped
Oct 12 13:48:03 vps0 openvpn[106793]: x:12384 MULTI: bad source address from client [10.58.140.49], packet dropped
Oct 12 13:48:03 vps0 openvpn[106793]: x:12384 MULTI: bad source address from client [10.58.140.49], packet dropped
Oct 12 13:48:04 vps0 openvpn[106793]: x:12384 MULTI: bad source address from client [10.58.140.49], packet dropped
Those packets may or may not be related to the DNS queries.
10.58.140.49 is strange and new. It's not from the subnet of the vpn (10.8.0.0/24) nor from the subnet of the local lan (192.168.173.0/24).
Anyway, another clue just found out is that doing bandwith tests with different online testers show that there's no upload done when going through the vpn. I'm looking forward to follow this lead.
Yet if anyone has any idea, I'll glady read it.
Re: Some web pages don't load
Posted: Wed Oct 12, 2022 12:46 pm
by TinCanTech
remre wrote: ↑Wed Oct 12, 2022 12:36 pm
10.58.140.49 is strange and new. It's not from the subnet of the vpn (10.8.0.0/24) nor from the subnet of the local lan (192.168.173.0/24).
Which is why they are dropped.
https://community.openvpn.net/openvpn/wiki/HOWTO
viewtopic.php?t=22603
Re: Some web pages don't load
Posted: Wed Oct 12, 2022 12:48 pm
by ordex
@remre have you tried reducing the MTU on the client side?
Something like: tun-mtu 1420
Re: Some web pages don't load
Posted: Wed Oct 12, 2022 4:32 pm
by TinCanTech
If there is an MTU problem between the client and server then both sides need to be configured correctly, no ?
And what about the comment in the manual:
- In most cases, you will probably want to leave this parameter set to its default value.
- It's best to use the --fragment and/or --mssfix options to deal with MTU sizing issues.
And it would be wiser to test the MTU prior to
blindly changing it.
Re: Some web pages don't load
Posted: Wed Oct 12, 2022 7:12 pm
by ordex
yeah, setting mssfix to 1420 might be better due to OpenVPN not handling super properly changes to the MTU.
This said, a quick test with tun-mtu 1420 may reveal something (or not).
Re: Some web pages don't load
Posted: Fri Oct 28, 2022 9:27 am
by remre
I finally took some time to dive into the hypothesis of the maximum transmission unit problem.
As it was said in the manuel for the
fragment option that
it should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead,
I tried to figure out my MTU. Changing this value to the experimental figure has been making the vpn working again !
I used
ping and its options
M et
s to determine the MTU. No change was therefore made to the initial openvpn configuration.
I guess my VPS provider changed one of its routers' MTU... Not pleasant but at the end instructing.
Thanks for your moral help and suggestions !
Cheers,
R.
Re: Some web pages don't load
Posted: Sat Oct 29, 2022 3:43 pm
by remre
Problem is back after one day and half. Yet another test from another computer with the same server and client configurations was working without reducing the maximum transmission unit/size.
I'm back at square one and lost. Testing another vps provider could be the next step.
To be continued.