VPN Director - This can't be right

[privacyguy123]

With VPN Director on:

tracert 8.8.8.8

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:

1 1 ms 1 ms 2 ms RT-AX58U-5468.lan [192.168.50.1]
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 27 ms 23 ms 24 ms dns.google [8.8.8.8]

With VPN Director off and Windows machine connected to the same VPN server with the same WireGuard config

tracert 8.8.8.8

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:

1 32 ms 35 ms 42 ms 10.2.0.1
2 * 91 ms 82 ms irb-144.as14-10g.lon3.uk.m247.ro [146.70.204.161]
3 121 ms 108 ms 104 ms 146.70.4.26
4 311 ms 150 ms 156 ms 146.70.4.100
5 103 ms 77 ms 74 ms 146.70.4.121
6 81 ms 73 ms 37 ms port-channel101.pni1.lon1.uk.m247.ro [83.97.21.87]
7 296 ms 41 ms 38 ms 142.250.161.148
8 46 ms 46 ms 74 ms 216.239.54.127
9 81 ms 75 ms 75 ms 172.253.66.101
10 245 ms 67 ms 66 ms dns.google [8.8.8.8]

What on earth is going on here?

 

[Viktor Jaep]

With VPN Director on:


With VPN Director off and Windows machine connected to the same VPN server with the same WireGuard config



What on earth is going on here?

How is VPN Director configured? How is your VPN tunnel configured? How is your WAN settings/DNS configured? How is your DNS Director configured? We're going to be grasping at straws unless you can provide a bit more info?

 

[privacyguy123]

VPN Director set to send all traffic to WGC1.
WAN DNS is bypassed by AdguardHome using DNS Director ...

 

[Viktor Jaep]

VPN Director set to send all traffic to WGC1.
WAN DNS is bypassed by AdguardHome using DNS Director ...

Unfortunately I'm not familiar with the inner workings and interactions between Wireguard, Adguardhome, VPN and DNS Director. Somebody else will have to help you out on that one... sorry!

 

[ZebMcKayhan]

VPN Director set to send all traffic to WGC1

Guess you have put a rule for your LAN to go over VPN. This rule does not cover the router itself so if you are running AGH on the router and dig not bind it to lan it will not use your vpn, it will use wan.
Not sure this info helps your issue though.

 

[ZebMcKayhan]

What on earth is going on here?

Traceroute sends out icmp packets with sequentially increased ttl value. Whenever this value reaches 0 your packet are not allowed to be forwarded anymore so this host sends back an icmp type 11 (time exceeded). The difference between this packet and a normal packet is that this comes for some other than the target destination.
So, it won't fall under ESTABLISHED rule in iptables, it will fall under RELATED rule.
Normally both is accepted in our routers but it certainly looks fishy.
I don't have the same problem running traceroute, it works perfectly from lan client via vpn Director to wgc1. Only difference is that I don't run agh.
Have you been fiddling with the iptables rules?

What if you run tracert with -n option to not reverse resolve queries? Any difference?

 

[privacyguy123]

Guess you have put a rule for your LAN to go over VPN. This rule does not cover the router itself so if you are running AGH on the router and dig not bind it to lan it will not use your vpn, it will use wan.
Not sure this info helps your issue though.

I don't think so? The NAT-PMP fix thing is so that when I run natpmpc -g 10.2.0.1 it goes over vpn and gets a reply with a port, without this rule it attemps to come from my ISP IP which obviously don't get a reply from the VPN server.

Traceroute sends out icmp packets with sequentially increased ttl value. Whenever this value reaches 0 your packet are not allowed to be forwarded anymore so this host sends back an icmp type 11 (time exceeded). The difference between this packet and a normal packet is that this comes for some other than the target destination.
So, it won't fall under ESTABLISHED rule in iptables, it will fall under RELATED rule.
Normally both is accepted in our routers but it certainly looks fishy.
I don't have the same problem running traceroute, it works perfectly from lan client via vpn Director to wgc1. Only difference is that I don't run agh.
Have you been fiddling with the iptables rules?

What if you run tracert with -n option to not reverse resolve queries? Any difference?

I should have specified this is tracert from a Windows PC, it doesn't seem to have a -n switch. With router VPN off all tracerts are fine, with ProtonVPN app connected on just Windows PC tracerts are all fine but when VPN director is on I see all those time outs. Any messing with iptables would be from scripts or entware stuff, otherwise I think I'm default.

Is there a way to output the rules for you to have a look over?

 

[ZebMcKayhan]

I should have specified this is tracert from a Windows PC, it doesn't seem to have a -n switch.

On tracert its -d to not resolve names...

Is there a way to output the rules for you to have a look over?

Sure, but it's tedious as it jumps from chain to chain. But the general command is

iptables -nvL FORWARD -t filter

Amongst the top rules there should be a rule to ACCEPT any ctstate RELATED, ESTABLISHED. Only rules above this rule would be of importance, since when this is hit it is accepted and will not continue traversing the chain.
Remove any public ip before posting.

 

[privacyguy123]

On tracert its -d to not resolve names...

Still all timeouts until the final destination.

Sure, but it's tedious as it jumps from chain to chain. But the general command is

iptables -nvL FORWARD -t filter

Amongst the top rules there should be a rule to ACCEPT any ctstate RELATED, ESTABLISHED. Only rules above this rule would be of importance, since when this is hit it is accepted and will not continue traversing the chain.
Remove any public ip before posting.

iptables -nvL FORWARD -t filter
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.50.2 udp dpt:48324 state NEW
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.50.2 tcp dpt:48324 state NEW
93M 102G IPSEC_DROP_SUBNET_ICMP all -- * * 0.0.0.0/0 0.0.0.0/0
93M 102G IPSEC_STRONGSWAN all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0 224.0.0.0/4
93M 102G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
40788 6487K WGSF all -- * * 0.0.0.0/0 0.0.0.0/0
40788 6487K OVPNSF all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 logdrop all -- !br0 eth4 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0
974 51312 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate DNAT
0 0 DNSFILTER_DOT tcp -- br+ * 0.0.0.0/0 0.0.0.0/0 tcp dpt:853
39814 6435K WGCF all -- * * 0.0.0.0/0 0.0.0.0/0
48 17612 OVPNCF all -- * * 0.0.0.0/0 0.0.0.0/0
48 17612 VPNCF all -- * * 0.0.0.0/0 0.0.0.0/0
48 17612 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0

 

[ZebMcKayhan]

Still all timeouts until the final destination.

2 different chains are called before:
IPSEC_DROP_SUBNET_ICMP
IPSEC_STRONGSWAN
Check so they are empty:

iptables -nvL IPSEC_DROP_SUBNET_ICMP
iptables -nvL IPSEC_STRONGSWAN

Besides from that it looks good

 

[privacyguy123]

Both empty yep.

Still something else up.

 

[ZebMcKayhan]

Both empty yep.

Still something else up.

Pretty sure that the issue is not on the router, but just to be sure, try to add a rule on your router:

iptables -I FORWARD -p icmp --icmp-type 11 -j ACCEPT

And test again.
Delete the rule once tested:

iptables -D FORWARD -p icmp --icmp-type 11 -j ACCEPT

 

[privacyguy123]

Pretty sure that the issue is not on the router, but just to be sure, try to add a rule on your router:

iptables -I FORWARD -p icmp --icmp-type 11 -j ACCEPT

And test again.
Delete the rule once tested:

iptables -D FORWARD -p icmp --icmp-type 11 -j ACCEPT

Still all timeouts on the Windows machine with that rule. In the router only hops 3 and 6 are * * * which I assume means timeout.

I still have connectivity but it seems odd every hope is timeout.

 

[ZebMcKayhan]

Still all timeouts on the Windows machine with that rule. In the router only hops 3 and 6 are * * * which I assume means timeout.

I still have connectivity but it seems odd every hope is timeout.

Not all hosts replies about dropped packets, so it's normal that one or 2 does time out. You could try with -w 5000 or something to increase timeout to 5sec and see if it makes a difference.

 

[ZebMcKayhan]

Still all timeouts on the Windows machine with that rule. In the router only hops 3 and 6 are * * * which I assume means timeout.

I still have connectivity but it seems odd every hope is timeout.

Found this, no solution though, but you are not alone. Possibly something is up with windows tracert.
https://answers.microsoft.com/en-us...the-hops/f56c1d38-9e6d-40e2-954e-45b67e82ee96
Could you try something else? I'm using PingTools for Android and it works fine over Asus-merlin router to wgc1.

 

[privacyguy123]

Found this, no solution though, but you are not alone. Possibly something is up with windows tracert.
https://answers.microsoft.com/en-us...the-hops/f56c1d38-9e6d-40e2-954e-45b67e82ee96
Could you try something else? I'm using PingTools for Android and it works fine over Asus-merlin router to wgc1.

PingUtils on Android is "no response" every hop till the last.

Seems like a router problem in the sense that both my Windows machine and Pi running Debian have all timeouts (* * *) until the very last hop with VPN Director on. I don't see this error while directly connected to ProtonVPN with their official app on the Windows machine.

The routers traceroute behaves differently altogether which is mind boggling.

 

[ZebMcKayhan]

Seems like a router problem in the sense that both my Windows machine and Pi running Debian have all timeouts (* * *) until the very last hop with VPN Director on.

Yet the same setup works for me.

I don't see this error while directly connected to ProtonVPN with their official app on the Windows machine.

That's what's makes this puzzling indeed.

Have you tried another destination than 8.8.8.8? Asus dns implementation is to add routes to dns... as this is a dns server it may end up differently. Try I.e google.com or something... it's a long shot and perhaps you already tried it...

 

[privacyguy123]

Yet the same setup works for me.



That's what's makes this puzzling indeed.

Have you tried another destination than 8.8.8.8? Asus dns implementation is to add routes to dns... as this is a dns server it may end up differently. Try I.e google.com or something... it's a long shot and perhaps you already tried it...

Tried many websites - all timeout until the last hop.

Reaching out to ProtonVPN support/community for input.

 

[ZebMcKayhan]

Tried many websites - all timeout until the last hop.

Reaching out to ProtonVPN support/community for input.

Still, since it's working with their official app the problem is probably on your side, and even if I'm reluctant to admit it, probably your router.
How complex is your policy routes, are you using fwmarks?
Could this be rp-filter related? Could you turn off rp filter on all your interfaces wan, wgc1, wgc2, wgs1 aso to see its not that?

 

[privacyguy123]

Still, since it's working with their official app the problem is probably on your side, and even if I'm reluctant to admit it, probably your router.
How complex is your policy routes, are you using fwmarks?
Could this be rp-filter related? Could you turn off rp filter on all your interfaces wan, wgc1, wgc2, wgs1 aso to see its not that?

I wouldn't be reluctant - the router has been headache after headache to be honest.

I use that Domain Based VPN Routing script which adds FWMarks, I believe they are all default ASUS though so nothing major changed there. Anything TrendMicro is turned off.

I ended up setting rp-filter to loose globally to fix other nonsense so it's not that ...