OpenVPN works but no access to LAN | Openvpn fonctionne mais pas d’accès au réseau local
-
is the Lan of "A" routed through the VPN tunnel that the pfSense on "B" uses?
The NAS is an enterprise NAS and therefore contains the Openvpn server but also Vms/Container and a Samba server which I can access from the LAN A directly obviously but also from an Openvpn Client.
Example current use that works correctly:
This midi I am at my place of work I turn on the Openvpn Client and connect me I recoit the address 10.8.0.6 which allowed me to access to one of the Vms of the network 192.168.10.0/24 in RDP but also I have access to the Samba in 192.168.10.xx and in 10.8.0.1So yes for me the Openvpn server works well with a simple Openvpn client and route well the Lan A machines to the Openvpn clients or the Pfsense server but unfortunately when I am on Lan B unable to access the Lan A machine
French :
Le NAS est un NAS entreprise et donc contient le serveur OpenVPN mais aussi des VMs/Container et un serveur Samba au quelle je peux accéder à partir du LAN A directement évidemment mais aussi à partir d'un Client OpenVPN.Exemple utilisation actuelle qui fonctionne correctement :
Ce midi je suis sur mon lieu de travail j'allume le Client OpenVPN et me connecte je recois l'adresse 10.8.0.6 ce qui m'a permit d'acceder à une des VMs du reseau 192.168.10.0/24 en RDP mais aussi j'ai acceder au Samba en 192.168.10.xx et en 10.8.0.1Donc oui pour moi le serveur OpenVPN fonctionne bien avec un simple client OpenVPN et route bien les machines du Lan A vers les clients OpenVPN ou le serveur PfSense mais malheureusement lorsque je suis sur le Lan B impossible d'acceder au machine du Lan A
Connexion OpenVPN activée
OK = "Nas 192.168.10.xx with (Serveur OpenVPN 10.8.0.1)" --> "Ping Pfsense 10.8.0.6" ==> "Ping OK" OK = "Pfsense Web-Interface" --> "Ping 192.168.10.1" --> "10.8.0.1" --> "192.168.10.1" ==> "Ping OK" OK = "Pfsense Web-Interface" --> "Ping 192.168.10.xxx" --> "10.8.0.1" --> "192.168.10.xxx" ==> "Ping OK" OK = "Pfsense Web-Interface" --> "Ping Google.com" --> "10.8.0.1" --> "192.168.10.1" --> "Google.com" ==> "Ping OK" OK = "Pfsense Web-Interface" --> "Traceroute 192.168.10.1" --> "10.8.0.1" --> "192.168.10.1" ==> "Traceroute OK" OK = "Pfsense Web-Interface" --> "Traceroute Google.com" --> "10.8.0.1" --> "192.168.10.1" --> "Google.com" ==> "Traceroute OK" OK = "VM pfsense 192.168.50.8" --> "Ping PfSense 192.168.50.1" ==> "Ping OK" KO = "VM pfsense 192.168.50.8" --> "Ping 192.168.10.1" ==> "Abnormal Error" KO = "VM pfsense 192.168.50.8" --> "Ping 192.168.10.xxx" ==> "Abnormal Error" KO = "VM pfsense 192.168.50.8" --> "Ping 10.8.0.1" ==> "Abnormal Error" KO = "VM pfsense 192.168.50.8" --> "Ping 8.8.8.8" ==> "Abnormal Error" KO = "VM pfsense 192.168.50.8" --> "Ping Google.com" ==> "Abnormal Error" KO = "VM pfsense 192.168.50.8" --> "Traceroute Google.com" ==> "Abnormal Error"Connexion OpenVPN désactivée
OK = "Nas 192.168.10.xx with (Serveur OpenVPN 10.8.0.1)" --> "Ping Pfsense 10.8.0.6" ==> "Normal Error" OK = "Pfsense Web-Interface" --> "Ping Google.com" ==> "Ping OK" OK = "Pfsense Web-Interface" --> "Traceroute Google.com" ==> "Traceroute OK" OK = "Pfsense Web-Interface" --> "Ping 192.168.10.1" ==> "Normal Error" OK = "Pfsense Web-Interface" --> "Ping 192.168.10.xxx" ==> "Normal Error" OK = "Pfsense Web-Interface" --> "Traceroute 192.168.10.1" ==> "Normal Error" OK = "VM pfsense 192.168.50.8" --> "Ping PfSense 192.168.50.1" ==> "Ping OK" OK = "VM pfsense 192.168.50.8" --> "Ping 192.168.10.1" ==> "Normal Error" OK = "VM pfsense 192.168.50.8" --> "Ping 192.168.10.xxx" ==> "Normal Error" OK = "VM pfsense 192.168.50.8" --> "Ping 10.8.0.1" ==> "Normal Error" OK = "VM pfsense 192.168.50.8" --> "Ping 8.8.8.8" ==> "Ping OK" OK = "VM pfsense 192.168.50.8" --> "Ping Google.com" ==> "Ping OK" OK = "VM pfsense 192.168.50.8" --> "Traceroute Google.com" ==> "Traceroute OK"So for me there’s probably something missing rules/option on pfsense but I’m blocking to find what? I don’t know.
French :
Donc pour moi il manque surement quelques chose règles/option sur pfsense mais mais je bloque a trouver quoi ? je n'en sais rien.Thank for help
-
@vincent1890
Check. The. Routing. -
Route on PfSense :
Sorry I failed to make a correct table0.0.0.0/1 10.8.0.5 UGS 106 1500 ovpnc1 default 62.210.zzz.1 UGS 419 1500 em0 10.8.0.0/24 10.8.0.5 UGS 1778 1500 ovpnc1 10.8.0.5 link#7 UH 0 1500 ovpnc1 10.8.0.6 link#7 UHS 0 16384 lo0 62.210.zzz.1/32 00:50:56:01:b4:e6 US 0 1500 em0 90.49.xxx.xxx/32 62.210.zzz.1 UGS 2149 1500 em0 127.0.0.1 link#4 UH 1777 16384 lo0 128.0.0.0/1 10.8.0.5 UGS 206 1500 ovpnc1 192.168.10.0/24 10.8.0.5 UGS 0 1500 ovpnc1 192.168.50.0/24 link#2 U 0 1500 em1 192.168.50.1 link#2 UHS 0 16384 lo0 212.129.yyy.yyy link#1 UHS 0 16384 lo0 212.129.yyy.yyy/32 link#1 U 0 1500 em090.49.xxx.xxx = IP SITE A (IP Public NAS)
212.129.yyy.yyy = IP SITE B (PfSense IP Failover)
62.210.zzz.1 = Gateway VM EsxiNAS IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface default Box.lan.prive 0.0.0.0 UG 100 0 0 qvs0 10.0.3.0 * 255.255.255.0 U 0 0 0 lxcbr0 10.0.5.0 * 255.255.255.0 U 0 0 0 docker0 10.6.0.0 * 255.255.255.0 U 0 0 0 qtun 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo 192.168.1.0 * 255.255.255.0 U 0 0 0 qvs2 192.168.10.0 * 255.255.255.0 U 0 0 0 qvs0 224.1.1.85 * 255.255.255.255 UH 0 0 0 qvs0PfSense WebInterface Traceroute with OpenVPN Enable
1 10.8.0.1 8.382 ms 7.970 ms 7.987 ms 2 192.168.10.1 7.984 ms 7.990 ms 8.005 ms 3 80.10.235.197 9.214 ms 8.641 ms 9.396 ms 4 193.253.151.126 15.094 ms 22.596 ms 18.401 ms 5 193.252.162.254 15.088 ms 14.990 ms 14.862 ms 6 193.252.137.74 15.632 ms 15.475 ms 15.990 ms 7 193.251.132.39 15.375 ms 193.251.243.45 15.489 ms 81.52.200.195 14.997 ms 8 72.14.202.100 15.113 ms 15.377 ms 72.14.204.184 15.590 ms 9 * 108.170.244.161 15.650 ms * 10 216.239.48.143 15.963 ms 15.576 ms 64.233.174.49 15.338 ms 11 8.8.8.8 15.479 ms 15.161 ms 15.331 msPfSense VM 192.168.50.8 Traceroute with OpenVPN Enable
1 192.168.50.1 0.125 ms 0.061 ms 0.056 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * ... ... ... ... ... Infinity.... -
The first routing that you posted, which pfSense is that? A? B? maybe C?
Don't get me wrong here, I really like to help you, but giving me only half the information or leaving out parts of it, leads to a guessing game that I'm not willing to play.
Looking at the last trace, I can see that the pfSense (A,B,C?) seems to send something out, but I do not know on which interface, if the packet really traverses through the VPN tunnel and if there's an answer on the other end that cannot be routed back.
Also it is not clear WHAT you are tracing. The whole information is missing some crucial parts.
Please, PLEASE provide complete information.
-
Let me clarify what I wrote before a bit.
The way I see it, what we have here is this:
On Site A there is some magic firewall that we don't know nothing about and it's also the default gateway. Also we have a system handing out IP-addresses via DHCP.
There's also a NAS, that plays VPN dialup vor the Windows clients, and when you connect with a Windows client it works.
- How is the NAS reachable from the outside for the VPN connection? Is there a port forwarding or something so that clients can reach the NAS from the outside?
- What device type are the clients using? I bet it's a TAP device and on the server side is a TAP device that is added to the local bridge so the clients aren't routed into the subnet on A but bridged.
- If the former is the case, then your current setup cannot work. Because now you're using ROUTING to connect to subnets together.
But that's just an educated guess. So if we follow this through, we run into a ton of problems again.
If I assume you're testing from pfSense on B and ping something in the subnet of A and we ASSSUME, that the route on pfSense-B is correctly set to point to subnet-A via the OpenVPN-tunnel, where we now ASSUME, that it's using a tun device and is actually routing, Then what's actually happening is this:
The pfSense-B checks the routing table, sees that it has to go through the tunnel and uses the tunnel's IP-address as the source address of your traceroute and your ping. Surprisingly we still haven't figured out if the clients in subnet-A are able to find their way to subnet-B because the route was set on the clients in subnet-A. But with the lack of that information, I highly doubt we know if the clients in subnet-A know how to ping the 10.0.8.0/24 tunnel or an address in it directly.
But I can only assume that's what's going on at this point, when I assume that you tried to ping something in subnet-A.
So before we even talk about anything packet filter or nat, the first thing you should do is to open ICMP from everywhere to everywhere on the firewalls of all the involved machines and then check if you can even ping from B to A. ICMP won't hurt anyone when it's any/any so, go ahead and test that.
If pinging is NOT possible then you have a problem on the routing level and not in the firewall.
Cu
-
Thank you for your patience
I’ll just put you a simple simplified picture of the network and I’ll try to answer and do the tests tomorrow within the day has all the questions.
-
Hi,
thanks for the "painting". Doesn't really help as it mixes up the different layers and doesn't really clarify the VPN situation. But nice colors.
One thing upfront: If you think hiding information, like IP-addresses of devices, for security reasons is a good idea, just let me know and we can close this thread immediately.
I'm not sure if my questions are lost in translation or you just don't understand what I'm asking for, but I still don't have the full picture.
I'm going to go with a lot of assumptions here, just to give you an idea on how it SHOULD be working.
So, let's look on the A-site first.
The NAS is playing VPN-server. As it is only a NAS and not a gateway, the clients on A don't use it as gateway or have any route pointing to the NAS. When you do a dial-in via Windows client you're using a TAP interface, which is layer 2 [1] and the clients are then bridged to the subnet on B. I can assume that's what's happening because you wrote that the clients get an IP-address from the DHCP-server on "A". The thing is it could be totally different. Brouting could be involved together with subnetting and a DHCP-relay. But who cares? Let's guess! I asked you to clarify on this, but still no information has been sent my way. Guess we just continue playing the guessing game and clicking around in the UI till it just magically starts working. With all the options that are there you should be done within a year or two.
Now you interconnect two subnets with each other, and unless they're both a /24 that are right next to each other and can be turned in one big /23 you're not able to use bridging on this. There are a million other reasons why bridging two networks together via VPN is a bad idea, but just let's stick with this.
The NAS has multiple interfaces, one of it seems to be in the 192.168.10.0/24 range, but the IP-address is yet to be announced I guess. Still no information here. But hey, we like to guess around, because that's way better than having hands on information - right?
Now the NAS also has an OpenVPN interface. Gladly we were able to filter the IP-address out in the pile of offered information. So we got something here. We also have the subnet of the tunnel, isn't that awesome? Yet we still don't know if we're using TAP or TUN interfaces here. I mean, it's not really important, just nice to know, you know?
Also we don't know how the NAS is using the tunnel interface. Is it put on the same bridge that the Windows clients are put on, or is it just dangling around in thin air? But why clarify? Let's guess!
So with all this information, we know shit about your network layout on A. We don't know what OS the NAS is running and if IP-forwarding is even enabled in said OS. It's a sad, but true story...
Now you painted this nice picture. Beautiful colors, but only a bit of information that creates more questions than it answers.
The NAS seems to be connected to multiple networks. Great! But how?
- Does it have an interface on said network?
- Is it using VLANs?
- Is it using routing? What gateways?
- Is the Docker network nated behind the docker host's ip-address?
- How is the situation when it comes to the LX containers?
- Should the NAS provide VPN-service to those networks?
Let me get my dice out....
So the things we know about Site-A:
- Subnet: 192.168.10.0/24
- NAS OpenVPN-Interface IP: 10.8.0.1/24
The things we DO NOT KNOW about Site-A:
- The stuff from above plus this...
- Are the Windows dial-in clients using TUN or TAP interfaces on the server side when using the VPN?
- Is the OpenVPN-server's device then added to a bridge or is brouting enabled via subnetting?
- What gateways are the local clients using?
- Do they know about B-site's subnet?
- Do they know about the subnet of the tunnel?
- Are there special routes on each gateway for the subnets on B?
- What is the IP-address of the NAS on 192.168.10.0/24 subnet?
- Is the NAS using a TAP or a TUN interface for the tunnel?
Now on "B"...
There is a pfSense running virtualized. It seems to be part of the B-network, yet we don't know the IP-address. I guess it was a good choice to hold it back for security reasons.
But it seems to have an IP-address on the tunnel to A that is 10.8.0.6/24
Things we do know about Site-B:
- pfSense's tunnel addres is 10.8.0.6/24
The things we DO NOT KNOW about Site-B:
- pfSense's IP-address in the local subnet
- Is the gateway "192.168.50.1" the pfSense box?
- What gateway are the clients using?
- Do the clients know about the other subnet?
- Do they know how to reach
So with all that missing information, how should anyone be able to help you?
Then you run tests from the network devices involved in creating the tunnel and routing packets through it, not knowing that those tests can be as wrong as they will ever get because a ping from pfSense uses totally different IP-addresses than a ping from one subnet to another, as pfSense checks its routing tables and based on that information it decides which network interface, which IP-address, to use. If those addresses are not known to the subnet you're trying to reach a machine in and you're not using the appropriate NAT settings, it CANNOT work.
- [1] - https://en.wikipedia.org/wiki/OSI_model
-
Hello
The first routing that you posted, which pfSense is that? A? B? maybe C?
The first routing I posted got in the Pfsense Web interface "PfSense->Web-Interfaces->Diagnostics->Routes"Destination Gateway Flags Use Mtu Netif Expire 0.0.0.0/1 10.8.0.5 UGS 106 1500 ovpnc1 default 62.210.zzz.1 UGS 419 1500 em0 10.8.0.0/24 10.8.0.5 UGS 1778 1500 ovpnc1 10.8.0.5 link#7 UH 0 1500 ovpnc1 10.8.0.6 link#7 UHS 0 16384 lo0 62.210.zzz.1/32 00:50:56:01:b4:e6 US 0 1500 em0 90.49.xxx.xxx/32 62.210.zzz.1 UGS 2149 1500 em0 127.0.0.1 link#4 UH 1777 16384 lo0 128.0.0.0/1 10.8.0.5 UGS 206 1500 ovpnc1 192.168.10.0/24 10.8.0.5 UGS 0 1500 ovpnc1 192.168.50.0/24 link#2 U 0 1500 em1 192.168.50.1 link#2 UHS 0 16384 lo0 212.129.yyy.yyy link#1 UHS 0 16384 lo0 212.129.yyy.yyy/32 link#1 U 0 1500 em0Looking at the last trace, I can see that the pfSense (A,B,C?) seems to send something out
The test is done as indicated in the title on the (VM 192.168.50.8 Site-B) which is linked to the Pfsense VM by the LAN 192.168.50.0/24but I do not know on which interface, if the packet really traverses through the VPN tunnel and if there's an answer on the other end that cannot be routed back.
Well pfsense interface of the 192.168.50.0/24 is em1, the packets precisely I don’t know if it really goes into VPN tunnel and I don’t know how to test this and so if there is an answer at the other end that can not be redirected.Also it is not clear WHAT you are tracing. The whole information is missing some crucial parts.
I do this test the "traceroute 192.168.10.110" and "traceroute 192.168.10.1" in a console from (VM 192.168.50.8 Site-B).On Site A there is some magic firewall that we don't know nothing about and it's also the default gateway. Also we have a system handing out IP-addresses via DHCP.
Yes actually on Site-A the firewall provided the DHCP, it is the default gateway.There's also a NAS, that plays VPN dialup vor the Windows clients, and when you connect with a Windows client it works.
Yes the NAS, which plays VPN dialup before Windows,Linux servers and when you connect with a Windows,Linux,Android,(macintosh never tested) client it works very well.How is the NAS reachable from the outside for the VPN connection? Is there a port forwarding or something so that clients can reach the NAS from the outside?
Yes a port transfer is made to the NAS so that customers can connect from the outside.What device type are the clients using? I bet it's a TAP device and on the server side is a TAP device that is added to the local bridge so the clients aren't routed into the subnet on A but bridged.
I don’t quite understand how to find this question but I think you want to know the configuration part of the openvpn server and so would say "tun" so here it is:dev tun keepalive 10 60 reneg-sec 0 persist-key persist-tun duplicate-cn script-security 3 client-to-client management localhost 7505 #username-as-common-name client-cert-not-required auth-user-pass-verify /usr/sbin/qvpn.sauth via-env ca /etc/openvpn/keys/ca.crt dh /etc/openvpn/keys/dh1024.pem key /etc/openvpn/keys/myserver.key cert /etc/openvpn/keys/myserver.crt client-connect /etc/openvpn/connect.sh client-disconnect /etc/openvpn/disconnect.sh status /var/log/openvpn-status.log writepid /var/run/openvpn.server.pid port 1194 proto tcp max-clients 5 server 10.8.0.0 255.255.255.0 push "dhcp-option DNS 192.168.10.1" push "redirect-gateway def1" comp-lzo cipher AES-256-CBC tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHAIf I assume you're testing from pfSense on B and ping something in the subnet of A and we ASSSUME, that the route on pfSense-B is correctly set to point to subnet-A via the OpenVPN-tunnel, where we now ASSUME, that it's using a tun device and is actually routing, Then what's actually happening is this:
The pfSense-B checks the routing table, sees that it has to go through the tunnel and uses the tunnel's IP-address as the source address of your traceroute and your ping.
If I ping or traceroute directly from the pfsense web interface I can actually reach the lan-A over the entire lan 192.168.10.0/24 but if I ping or traceroute from the (VM 192.168.50.8 Site-B) this time impossible to arrive at destination.Surprisingly we still haven't figured out if the clients in subnet-A are able to find their way to subnet-B because the route was set on the clients in subnet-A.
No SITE-A clients do not save how to ping the VPN tunnel or SITE-B.But with the lack of that information, I highly doubt we know if the clients in subnet-A know how to ping the 10.0.8.0/24 tunnel or an address in it directly.
No SITE-A customers do not save how to ping tunnel 10.0.8.0/24 or address directly.But I can only assume that's what's going on at this point, when I assume that you tried to ping something in subnet-A.
So before we even talk about anything packet filter or nat, the first thing you should do is to open ICMP from everywhere to everywhere on the firewalls of all the involved machines and then check if you can even ping from B to A. ICMP won't hurt anyone when it's any/any so, go ahead and test that.Webinterface Pfsense to LAN-A ping TEST:
Source address : LAN PING 192.168.10.110 (192.168.10.110) from 192.168.50.1: 56 data bytes --- 192.168.10.110 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss ____________________________ Source address : OpenVPN client : NasOpenVPN PING 192.168.10.110 (192.168.10.110) from 10.8.0.6: 56 data bytes 64 bytes from 192.168.10.110: icmp_seq=0 ttl=127 time=30.072 ms 64 bytes from 192.168.10.110: icmp_seq=1 ttl=127 time=8.444 ms 64 bytes from 192.168.10.110: icmp_seq=2 ttl=127 time=8.128 ms --- 192.168.10.110 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.128/15.548/30.072/10.271 ms ____________________________ Source address : Automatically selected (default) PING 192.168.10.1 (192.168.10.1): 56 data bytes 64 bytes from 192.168.10.1: icmp_seq=0 ttl=63 time=28.935 ms 64 bytes from 192.168.10.1: icmp_seq=1 ttl=63 time=8.602 ms 64 bytes from 192.168.10.1: icmp_seq=2 ttl=63 time=8.159 ms --- 192.168.10.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.159/15.232/28.935/9.691 msOne thing upfront: If you think hiding information, like IP-addresses of devices, for security reasons is a good idea, just let me know and we can close this thread immediately.
Not only the public IP address I prefer not to make them visible and seems irrelevant to me but the internal addresses no I don’t care a bit because it is the internal network I simply hid them to avoid making a mistake one day by looking at this diagram that does not It was simply more up-to-date and I didn’t think you really needed what I replaced.I'm not sure if my questions are lost in translation or you just don't understand what I'm asking for, but I still don't have the full picture.
Well the actually I don’t understand exactly what you want as additional info:
Routes on router SITE-A or other things still I’m sorry to not understand what info you want?The NAS has multiple interfaces, one of it seems to be in the 192.168.10.0/24 range, but the IP-address is yet to be announced I guess. Still no information here.
The NAS as ip on the network 192.168.10.30Yet we still don't know if we're using TAP or TUN interfaces here. I mean, it's not really important, just nice to know, you know?
TUN interfacesAlso we don't know how the NAS is using the tunnel interface. Is it put on the same bridge that the Windows clients are put on, or is it just dangling around in thin air? But why clarify? Let's guess!
Sorry I don’t understand the request exactly so I put the config file up above but tell me if this isn’t going to get the desired information by ssh command for example or otherwise.So with all this information, we know shit about your network layout on A. We don't know what OS the NAS is running and if IP-forwarding is even enabled in said OS. It's a sad, but true story...
Model : NAS Qnap TS-877
OS :Linux
Version "QTS 4.4.1 (20191206)"sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1Thank you for having help and this time I hope to have given the necessary elements for progress on the problem.
Bye
-
Simplement un message pour dire que le problème est résolu et que cela était bien un problème de configuration au niveau PfSense et que je passerais dans quelques heures/jours mettre un tuto sur la façon exacte d'installer et configurer le PfSense et surement aussi OpnSense pour les personnes dans ma situation/environnent réseau.
Merci à @Grimeton pour son aide, malgré le fait que j'ai trouvé seul la solution après encore une nuit acharnée de test.
--------------------
--------------------Just a message to say that the problem is solved and that this was indeed a configuration problem at the Pfsense level and that I would come by in a few hours/days to put a tutorial on the exact way to install and configure the Pfsense and surely also Opnsense for the people in my situation/environment network.
Thanks to @Grimeton for his help, despite the fact that I found the solution alone after another hard night of testing.
-
Hello The first routing that you posted, which pfSense is that? A? B? maybe C? The first routing I posted got in the Pfsense Web interface "PfSense->Web-Interfaces->Diagnostics->Routes"Yeah.
Nevermind.
I give up.
I asked you on which machine you got this routing table and still you are not able to provide that information.
Have fun figuring this out, but I'm not gonna waste my time here. Maybe paid support will get you anywhere. They can help you here:
https://www.netgate.com/support/
Nice talking to you!
Have a nice day!
KR,
G.
