OpenVPN works but no access to LAN | Openvpn fonctionne mais pas d’accès au réseau local



  • Greetings to you all,

    I am trying to configure Openvpn Client on Pfsense and I need help or advice. I read all the relevant documentation and messages of the forum, but without success maheureusement.

    I have a NAS that hosts (Openvpn server 10.8.0.1) on the Site A network LAN.
    My servers on the Site A LAN get addresses via ubiquity 192.168.10.0/24 DHCP router leases with Openvpn client on windows I can easily access the 192.168.10.0/24 networks via Openvpn.
    I have now added a Pfsense VM on one (dedicated Esxi server call Site B) and so sat outside Site A. The pfSense server LAN is 192.168.50.0/24
    To set this up I followed the following tutorials:
    https://www.supinfo.com/articles/single/3103-creation-vpn-site-to-site-deux-pfsense-openvpn
    https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/routing-internet-traffic-through-a-site-to-site-openvpn-connection-in-pfsense-2-1.html

    My problem is that the Openvpn Client works and I can connect, but I cannot ping or connect to any server on my remote Site A LAN.

    For more precision here is the current behavior:

    -----------------------------------------------------

    French :

    Salut à tous,

    J'essaie de configurer OpenVPN Client sur PfSense et j'ai besoin d'aide ou de conseils. J'ai lu toute la documentation et les messages pertinents du forum, mais sans succès malheureusement.

    J'ai un NAS qui héberge (OpenVPN server 10.8.0.1) sur le lan réseau Site A.
    Mes serveurs sur le LAN Site A obtiennent des adresses via des baux DHCP routeur ubiquity 192.168.10.0/24 avec client OpenVPN sur windows je peux accéder sans problème aux réseaux 192.168.10.0/24 par l’intermédiaire OpenVPN.
    J'ai maintenant ajouté une VM PfSense sur un (serveur dedié Esxi appelons le Site B) et donc situé à l’extérieur du Site A. Le LAN du serveur pfSense est 192.168.50.0/24

    Pour mettre cela en place j'ai suivi les tutos suivants :
    https://www.supinfo.com/articles/single/3103-creation-vpn-site-to-site-deux-pfsense-openvpn
    https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/routing-internet-traffic-through-a-site-to-site-openvpn-connection-in-pfsense-2-1.html

    Mon problème est que le Client OpenVPN fonctionne et que je peux me connecter, mais je ne peux pas ping ou me connecter à aucun serveur de mon réseau local distant Site A.

    Pour plus de précision voila le comportement actuelle :


    Connection OpenVPN actived

    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 192.168.50.8" --> "Ping PfSense 192.168.50.1" ==> "Ping OK"
    KO = "VM 192.168.50.8" --> "Ping 192.168.10.1" ==> "Abnormal Error"
    KO = "VM 192.168.50.8" --> "Ping 192.168.10.xxx" ==> "Abnormal Error"
    KO = "VM 192.168.50.8" --> "Ping 10.8.0.1" ==> "Abnormal Error"
    KO = "VM 192.168.50.8" --> "Ping 8.8.8.8" ==> "Abnormal Error"
    KO = "VM 192.168.50.8" --> "Ping Google.com" ==> "Abnormal Error"
    KO = "VM 192.168.50.8" --> "Traceroute Google.com" ==> "Abnormal Error"
    

    Connection OpenVPN deactivated

    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 192.168.50.8" --> "Ping PfSense 192.168.50.1" ==> "Ping OK"
    OK = "VM 192.168.50.8" --> "Ping 192.168.10.1" ==> "Normal Error"
    OK = "VM 192.168.50.8" --> "Ping 192.168.10.xxx" ==> "Normal Error"
    OK = "VM 192.168.50.8" --> "Ping 10.8.0.1" ==> "Normal Error"
    OK = "VM 192.168.50.8" --> "Ping 8.8.8.8" ==> "Ping OK"
    OK = "VM 192.168.50.8" --> "Ping Google.com" ==> "Ping OK"
    OK = "VM 192.168.50.8" --> "Traceroute Google.com" ==> "Traceroute OK"
    

    OpenVPN Client configuration in PfSense

    Generale information
    Server mode: (SSL/TLS + User Auth)
    Protocol: (TCP on IPv4)
    Device mode: (tun - Layer 3 Tunnel Mode)
    Interface: WAN
    Server host: IP
    Server port: 1194

    Tunnel Settings
    IPv4 Tunnel Network: 10.8.0.0/24
    IPv4 Local Network/s: 192.168.10.0/24
    Compression LZO Compression
    Topology: Subnet -- One IP adress per client...
    Type-of-Service: unchecked
    Don't pull routes: unchecked
    Don't add/remove routes: unchecked

    Advanced Configuration
    Custum options: auth-nocache


    Rules configuration in PfSense

    WAN Rules: (Rules by default)
    | Protocol | Source | Port | Destination | Port | Gateway | Queue | Schedule | Description |
    | * | RFC 1918 networks | * | * | * | * | * | | Block private networks |
    | * | Reserved Not assigned by IANA | * | * | * | * | * | | Block bogon networks |

    LAN Rules: (Rules by default)
    | Protocol | Source | Port | Destination | Port | Gateway | Queue | Schedule | Description |
    | * | * | * | LAN Address | 443 80 | * | * | | Anti-Lockout Rule |
    | IPv4 * | LAN NET | * | * | * | * | none | | Default allow LAN to any rule |
    | IPv6 * | LAN NET | * | * | * | * | none | | Default allow LAN IPv6 to any rule |

    OpenVPN Rules: (Rules added by me)
    | Protocol | Source | Port | Destination | Port | Gateway | Queue | Schedule | Description |
    | IPv4 * | * | * | * | * | * | none | | OpenVPN |

    NAT Outbound (Manuel Outbound NAT rule generation) (Rules added by me)
    | Interface | Source | Source Port | Destination | Destination Port | NAT Address | NAT Port | Static Port | Description |
    | WAN | any | * | * | * | Wan Address | * | <-> | Wan-Outbound |




  • Hi,

    is the Lan of "A" routed through the VPN tunnel that the pfSense on "B" uses?
    Is the pfSense on "B" the default gateway for the clients on "B"? If that is not the case, the clients need to know that "A"'s subnet is reachable via B's pfSense.

    Also "A" needs to know how to reach "B"'s subnet. Either via routing, brouting or nating. Whatever you do, pick your poison.

    Cu



  • is the Lan of "A" routed through the VPN tunnel that the pfSense on "B" uses?
    Yes the Lan A normally should be able to be accessed on Lan B unfortunately currently does not work and I do not understand why probably a missing rule or something else but I do not find.

    Is the pfSense on "B" the default gateway for the clients on "B"?
    Yes Lan B 192.168.50.0/24 a as gateway 192.168.50.1

    If that is not the case, the clients need to know that "A"'s subnet is reachable via B's pfSense.
    How exactly I really do not know pfsense well

    Also "A" needs to know how to reach "B"'s subnet. Either via routing, brouting or nating. Whatever you do, pick your poison.
    What is the best solution because on the NAS (Openvpn server) I am not really the hand on the system because of the fact that it is a prefabricated NAS but I have control over all the rest of the system Router/Switch/Wifi network.?


    le Lan de "A" est-il acheminé via le tunnel VPN utilisé par pfSense sur "B"?
    Oui le Lan A normalement devrais pouvoir être accessible sur lan B malheureusement actuellement ne fonctionne pas et je comprend pas pourquoi surement une regles manquante ou autre chose mais je ne trouve pas.

    Le pfSense sur "B" est-il la passerelle par défaut pour les clients sur "B"?
    Oui Lan B 192.168.50.0/24 a comme gateway 192.168.50.1

    Si ce n'est pas le cas, les clients doivent savoir que le sous-réseau de "A" est accessible via pfSense de B.
    De quelle façon exactement je ne connais vraiment pas bien pfsense

    Aussi "A" doit savoir comment atteindre le sous-réseau de "B". Soit via le routage, broutage ou nating. Quoi que vous fassiez, choisissez votre option.
    Quel est la meilleurs solution car sur le NAS (OpenVPN server) je n'est pas vraiment la main sur le system a cause du fait que cela soit un NAS préfabriqué par contre j'ai la main sur tous le reste du system réseau Routeur/Switch/Wifi.?



  • To be sure that I have explained myself well and that your questions and my answers correspond here is a small simple diagram of the current network and what I am trying to do
    Thank you so much for your help

    Current what works with Openvpn client on linux or windows

    external computer 10.8.0.yyy via Client OpenVPN
    |
    |
    modem (WAN address)
    |
    |
    Internet
    |
    |
    modem (WAN address)
    |
    |
    Nas (IP OpenVPN 10.8.0.0/24) (OpenVPN server)
    |
    |
    internal computer 192.168.10.yyy


    I would want that

    PfSense LAN 192.168.50.1
    |
    |
    PfSense 10.8.0.yyy via Client OpenVPN
    modem (WAN address)
    |
    |
    Internet
    |
    |
    modem (WAN address)
    |
    |
    Nas (IP OpenVPN 10.8.0.0/24) (OpenVPN server)
    |
    |
    internal computer 192.168.10.yyy



  • @vincent1890 said in 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?
    Yes the Lan A normally should be able to be accessed on Lan B unfortunately currently does not work and I do not understand why probably a missing rule or something else but I do not find.

    "Should be", "Could be", "Must be". We do not want to assume, WE WANT TO KNOW.

    So check your setup and answer my question regarding the routing.

    Is the pfSense on "B" the default gateway for the clients on "B"?
    Yes Lan B 192.168.50.0/24 a as gateway 192.168.50.1

    If that is not the case, the clients need to know that "A"'s subnet is reachable via B's pfSense.
    How exactly I really do not know pfsense well

    Also "A" needs to know how to reach "B"'s subnet. Either via routing, brouting or nating. Whatever you do, pick your poison.
    What is the best solution because on the NAS (Openvpn server) I am not really the hand on the system because of the fact that it is a prefabricated NAS but I have control over all the rest of the system Router/Switch/Wifi network.?

    I don't understand why you use a NAS as VPN-server in the first place. You put all this stuff on a firewall/router where you know that packets traverse through the machine anyway.

    Setting up brouting is something that can become very dangerous very quickly if you do not have the network under full control, so it's out of the picture here.

    You either move the VPN-server over to the default gateway on A or you have to distribute routes to B via DHCP on A and change all the configurations of the static machines on A.

    Cu


    le Lan de "A" est-il acheminé via le tunnel VPN utilisé par pfSense sur "B"?
    Oui le Lan A normalement devrais pouvoir être accessible sur lan B malheureusement actuellement ne fonctionne pas et je comprend pas pourquoi surement une regles manquante ou autre chose mais je ne trouve pas.

    Le pfSense sur "B" est-il la passerelle par défaut pour les clients sur "B"?
    Oui Lan B 192.168.50.0/24 a comme gateway 192.168.50.1

    Si ce n'est pas le cas, les clients doivent savoir que le sous-réseau de "A" est accessible via pfSense de B.
    De quelle façon exactement je ne connais vraiment pas bien pfsense

    Aussi "A" doit savoir comment atteindre le sous-réseau de "B". Soit via le routage, broutage ou nating. Quoi que vous fassiez, choisissez votre option.
    Quel est la meilleurs solution car sur le NAS (OpenVPN server) je n'est pas vraiment la main sur le system a cause du fait que cela soit un NAS préfabriqué par contre j'ai la main sur tous le reste du system réseau Routeur/Switch/Wifi.?



  • 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.1

    So 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.1

    Donc 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.



  • @Grimeton

    Route on PfSense :
    Sorry I failed to make a correct table

    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	em0
    

    90.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 Esxi

    NAS 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 qvs0
    

    PfSense 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 ms
    

    PfSense 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.

    alt text



  • 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.



  • 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	em0
    

    Looking 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/24

    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.
    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-SHA
    

    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.
    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 ms
    

    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.
    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.30

    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?
    TUN interfaces

    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!
    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 = 1

    Thank 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.


Log in to reply