VPN Director - This can't be right

[ZebMcKayhan]

I use that Domain Based VPN Routing script which adds FWMarks

Could you disable this script temporarily to see if that changes anything.


Another thing to test, what if you add a vpndirector rule to send your computer to wan all else as it was. Does traceroute work on that computer then?

As I don't have this problem, but I'm only running Unbound and Diversion. But I don't see AGH to be causing this. Are you running any other scripts?

 

[privacyguy123]

Could you disable this script temporarily to see if that changes anything.


Another thing to test, what if you add a vpndirector rule to send your computer to wan all else as it was. Does traceroute work on that computer then?

As I don't have this problem, but I'm only running Unbound and Diversion. But I don't see AGH to be causing this. Are you running any other scripts?

VPN Routing script seemed to have a "Kill" option within it and tracerts are still broken with it off.

I think what you're asking is to turn off VPN Director for this Windows machine? I said in the first post with VPN Director off traceroutes are fine.

EDIT: Nothing in Windows routes seems wrong to me either.

route print
===========================================================================
Interface List
18...90 78 41 31 d6 8a ......Microsoft Wi-Fi Direct Virtual Adapter #3
21...92 78 41 31 d6 89 ......Microsoft Wi-Fi Direct Virtual Adapter #4
13...90 78 41 31 d6 89 ......Intel(R) Wi-Fi 6 AX200 160MHz
1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.50.1 192.168.50.2 35
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.50.0 255.255.255.0 On-link 192.168.50.2 291
192.168.50.2 255.255.255.255 On-link 192.168.50.2 291
192.168.50.255 255.255.255.255 On-link 192.168.50.2 291
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.50.2 291
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.50.2 291
===========================================================================
Persistent Routes:
None

IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 331 ::1/128 On-link
1 331 ff00::/8 On-link
===========================================================================
Persistent Routes:
None

 

[ZebMcKayhan]

I think what you're asking is to turn off VPN Director for this Windows machine? I said in the first post with VPN Director off traceroutes are fine.

Yea, I guess... you cannot turn vpn Director off you can only enable/disable routes.
Instead of disabling your lan2wgc1 rule, try to add an additional rule for your computer ip to wan. Maybe this is what you are doing.

Just as a test, if you reboot your router without USB drive. This would disable ALL 3rd party scripts... just to test if there is anything interfering.

As far as I can see your firewall is not blocking, the routes should work fine, rp-filter is not involved... what else could it be???
If it still doesn't work without all add-ons then perhaps it is your vpn supplier. At least I don't have any better idea.

 

[privacyguy123]

Yea, I guess... you cannot turn vpn Director off you can only enable/disable routes.
Instead of disabling your lan2wgc1 rule, try to add an additional rule for your computer ip to wan. Maybe this is what you are doing.

Just as a test, if you reboot your router without USB drive. This would disable ALL 3rd party scripts... just to test if there is anything interfering.

As far as I can see your firewall is not blocking, the routes should work fine, rp-filter is not involved... what else could it be???
If it still doesn't work without all add-ons then perhaps it is your vpn supplier. At least I don't have any better idea.

Adding that uncloaks my IP from VPN to ISP which is obviously not what I want ...

 

[ZebMcKayhan]

Adding that uncloaks my IP from VPN to ISP which is obviously not what I want ...

View attachment 53874

I know, but it's just a temporary test. Delete the rule when the test is gone...

 

[privacyguy123]

I know, but it's just a temporary test. Delete the rule when the test is gone...

Sorry, tracerts *were* working with that rule on. WireGuard tunnel is for sure breaking something ... or it's a ProtonVPN server thing.

 

[ZebMcKayhan]

Sorry, tracerts *were* working with that rule on. WireGuard tunnel is for sure breaking something ...

Anything shows up in the router syslog when running traceroute that fails that may indicating firewall dropping packets?

 

[privacyguy123]

Anything shows up in the router syslog when running traceroute that fails that may indicating firewall dropping packets?

To be honest the Dropped log is so chocker block with port scans - it seems Virgin Medias Hub in Bridged mode has some sort of shared IP that is under attack literally 24/7 - I never notice anything OUTBOUND blocked, though. Not after running a tracert anyway.

 

[ZebMcKayhan]

To be honest the Dropped log is so chocker block with port scans - it seems Virgin Medias Hub in Bridged mode has some sort of shared IP that is under attack literally 24/7 - I never notice anything OUTBOUND blocked, though. Not after running a tracert anyway.

No, it wouldn't be OUTBOUND, it would be if there is a problem with recieving/forwarding the icmp type 11 reply from the host (inbound). If it is sorted as ctstate invalid for example.

Another way to check is to check the forward filter chain and keep track of the packet count before and after running a failed traceroute. Notice if any of the DROP rules systematically are increased after each failed traceroute.

 

[privacyguy123]

No, it wouldn't be OUTBOUND, it would be if there is a problem with recieving/forwarding the icmp type 11 reply from the host (inbound). If it is sorted as ctstate invalid for example.

Another way to check is to check the forward filter chain and keep track of the packet count before and after running a failed traceroute. Notice if any of the DROP rules systematically are increased after each failed traceroute.

Using that command you supplied me earlier in the thread?

iptables -nvL FORWARD -t filter

Or?

 

[ZebMcKayhan]

Using that command you supplied me earlier in the thread?

iptables -nvL FORWARD -t filter

Or?

Yep...

Edit:

iptables -Z

Could be used to reset the counters if it makes it easier for you...

 

[privacyguy123]

Yep...

This is the only rule that mentions DROP and doesn't seem to change at all

iptables -nvL FORWARD -t filter | grep DROP
66M 76G IPSEC_DROP_SUBNET_ICMP all -- * * 0.0.0.0/0 0.0.0.0/0

 

[ZebMcKayhan]

This is the only rule that mentions DROP and doesn't seem to change at all

Looks like your and mine differs:

admin@RT-AX86U_Pro:/tmp/home/root# iptables -nvL FORWARD -t filter | grep DROP
 121M  175G IPSEC_DROP_SUBNET_ICMP  all  --  *      * 0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  !br0   eth0    0.0.0.0/0        0.0.0.0/0
33380 1545K DROP       all  --  *      *       0.0.0.0/0        0.0.0.0/0            state INVALID
    0     0 DROP       all  --  *      *       0.0.0.0/0        0.0.0.0/0

Checked you dump in previous post, try

iptables -nvL FORWARD -t filter | grep logdrop

Also, you might consider resetting the pkt counter as it's hard to see single packets when the counter is counting 66M(illions)

 

[privacyguy123]

Looks like your and mine differs:

admin@RT-AX86U_Pro:/tmp/home/root# iptables -nvL FORWARD -t filter | grep DROP
 121M  175G IPSEC_DROP_SUBNET_ICMP  all  --  *      * 0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  !br0   eth0    0.0.0.0/0        0.0.0.0/0
33380 1545K DROP       all  --  *      *       0.0.0.0/0        0.0.0.0/0            state INVALID
    0     0 DROP       all  --  *      *       0.0.0.0/0        0.0.0.0/0

Checked you dump in previous post, try

iptables -nvL FORWARD -t filter | grep logdrop

Also, you might consider resetting the pkt counter as it's hard to see single packets when the counter is counting 88M(illions)

iptables -nvL FORWARD -t filter | grep logdrop
0 0 logdrop all -- !br0 eth4 0.0.0.0/0 0.0.0.0/0
1086 54078 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0

Numbers went from that to this after failed tracert

iptables -nvL FORWARD -t filter | grep logdrop
0 0 logdrop all -- !br0 eth4 0.0.0.0/0 0.0.0.0/0
1087 54118 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0

Keep in mind this is while the Virgin IP is getting blasted with port scans in the firewall log ...

 

[ZebMcKayhan]

Numbers went from that to this after failed tracert

How about

iptables -nvL WGCF | grep DROP

or "logdrop" if that is how your rule is defined

Looks like there is only a single packet drop... I would expect atleast 10pkts from all hosts trying to send each it's time exceeded packet

 

[privacyguy123]

This ones too many packets, how do I reset it?

iptables -nvL WGCF | grep DROP
626 869K DROP all -- wgc1 * 0.0.0.0/0 0.0.0.0/0

 

[ZebMcKayhan]

This ones too many packets, how do I reset it?

iptables -Z

 

[privacyguy123]

iptables -Z

Neither the previous output this new WGCF one moved from 0 after failed tracert.

 

[ZebMcKayhan]

Neither the previous output this new WGCF one moved from 0 after failed tracert.

Then I can't see that your router is blocking anything. Have no idea why this is not working for you, whilst it is working for me... check what proton is responding...

 

[privacyguy123]

Then I can't see that your router is blocking anything. Have no idea why this is not working for you, whilst it is working for me... check what proton is responding...

Awaiting update from their support staff ... it could be their apps modify the packets in some way in order to get a reply?