Openvpn site-to-site: client cannot ping openvpn server and server lan



  • Dear pfSense community,
    I set up an openvpn server on a pfSense gateway and an OpenVPN client on another pfSense gateway so as to implement a site-to-site openvpn. The client connects to the server and ping the openvpn server and its LAN and all the devices connected to the server openvpn lan. While the server and the devices connected to its LAN cannot ping LAN client and the devices connected to it.

    The server subnet LAN is 192.168.10.0/24, and has access to the internet via two ADSL lines. The wan1 is 192.168.99.0/24 while WAN2 is 192.168.88.0/24. I configured a Load Balancing these two WAN connections.

    The client's subnet is 192.168.8.0/24. The ping client also LAN wan1 and WAN2.

    The subnet of the lan openvpn is 172.16.23.0/24.

    The /var/etc/openvpn/server1.conf configuration file is as follows:

    **dev ovpns1
    verb 1
    dev-type tun
    tun-ipv6
    dev-node /dev/tun1
    writepid /var/run/openvpn_server1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-128-CBC
    auth SHA1
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 192.168.88.102
    tls-server
    server 172.16.23.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc/server1
    ifconfig 172.16.23.1 172.16.23.2
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'doppiacr' 1"
    lport 1194
    management /var/etc/openvpn/server1.sock unix
    ca /var/etc/openvpn/server1.ca
    cert /var/etc/openvpn/server1.cert
    key /var/etc/openvpn/server1.key
    dh /etc/dh-parameters.1024
    crl-verify /var/etc/openvpn/server1.crl-verify
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo adaptive
    topology subnet
    push "route 192.168.10.0 255.255.255.0"

    push "route 192.168.99.0 255.255.255.0"

    push "route 192.168.88.0 255.255.255.0"

    route 192.168.8.0 255.255.255.0**

    The client configuration file is as follows:

    verb 3
    dev-type tun
    tun-ipv6
    dev-node /dev/tun1
    writepid /var/run/openvpn_client1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-128-CBC
    auth SHA1
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 192.168.55.7
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client1.sock unix
    remote qualcosa.no-ip.org 1194
    ca /var/etc/openvpn/client1.ca
    cert /var/etc/openvpn/client1.cert
    key /var/etc/openvpn/client1.key
    tls-auth /var/etc/openvpn/client1.tls-auth 1
    comp-lzo adaptive
    resolv-retry infinite

    The openvpn server routing table after the client connection is as follows:

    IPv4 Routes
    Destination Gateway Flags Use Mtu Netif Expire
    default 192.168.88.254 UGS 214294 1500 re1
    127.0.0.1 link#8 UH 516 16384 lo0
    172.16.23.0/24 172.16.23.1 UGS 0 1500 ovpns1
    172.16.23.1 link#9 UHS 0 16384 lo0
    172.16.23.2 link#9 UH 268 1500 ovpns1
    172.16.24.0/24 172.16.24.1 UGS 0 1500 ovpns2
    172.16.24.1 link#10 UHS 0 16384 lo0
    172.16.24.2 link#10 UH 712510 1500 ovpns2
    192.168.8.0/24 172.16.23.2 UGS 0 1500 ovpns1
    192.168.10.0/24 link#3 U 0 1500 re2
    192.168.10.1 link#3 UHS 0 16384 lo0
    192.168.55.0/24 172.16.24.2 UGS 6 1500 ovpns2
    192.168.88.0/24 link#2 U 2041166 1500 re1
    192.168.88.102 link#2 UHS 0 16384 lo0
    192.168.99.0/24 link#1 U 2043033 1500 re0
    192.168.99.5 link#1 UHS 0 16384 lo0
    208.67.220.220 192.168.88.254 UGHS 1350 1500 re1
    208.67.222.222 192.168.99.1 UGHS 1350 1500 re0

    The routing table of the client is as follows:

    IPv4 Routes
    Destination Gateway Flags Use Mtu Netif Expire
    default 192.168.55.254 UGS 22707 1500 re0
    8.8.4.4 192.168.55.254 UGHS 0 1500 re0
    8.8.8.8 192.168.55.254 UGHS 0 1500 re0
    127.0.0.1 link#7 UH 115 16384 lo0
    172.16.23.0/24 172.16.23.2 UGS 0 1500 ovpnc1
    172.16.23.1 link#9 UH 1864 1500 ovpnc1
    172.16.23.2 link#9 UHS 0 16384 lo0
    192.168.8.0/24 link#3 U 60191 1500 re2
    192.168.8.1 link#3 UHS 0 16384 lo0
    192.168.10.0/24 172.16.23.1 UGS 27 1500 ovpnc1
    192.168.55.0/24 link#1 U 12244 1500 re0
    192.168.55.7 link#1 UHS 0 16384 lo0
    192.168.88.0/24 172.16.23.1 UGS 0 1500 ovpnc1
    192.168.99.0/24 172.16.23.1 UGS 0 1500 ovpnc1
    208.67.220.220 192.168.55.254 UGHS 3 1500 re0
    208.67.222.222 192.168.55.254 UGHS 5 1500 re0

    The firewall OpenVPN_SERVER rules are of the following servers:

    **Rules (Drag to Change Order)
    States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
    0/234 KiB         IPv4 *     *           *     * *   * none    **

    The firewall LAN rules are of the following servers:
    see attached image (lan server firewall.jpg)

    The client firewall OpenVPN_CLIENT rules are as follows:

    **Rules (Drag to Change Order)
    States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
    0/0 B         IPv4 *     *           *     * *   * none    **

    The client firewall LAN rules are as follows:
    see attached image  (lan client firewall.jpg)

    These are the configurations. The problem I have is that the LAN server can not access the LAN client. An idea what might be the solution? Thank you.

    ![lan server firewall.jpg](/public/imported_attachments/1/lan server firewall.jpg)
    ![lan server firewall.jpg_thumb](/public/imported_attachments/1/lan server firewall.jpg_thumb)
    ![lan client firewall.jpg](/public/imported_attachments/1/lan client firewall.jpg)
    ![lan client firewall.jpg_thumb](/public/imported_attachments/1/lan client firewall.jpg_thumb)



  • Is the clients side pfSense the default gateway in its LAN?



  • virago mann many thanks for your quick response.
    No, the default gateway is the IP of the ADSL router to which the pfSense device is connected. Attach a picture of the setup.

    ![client default gateway.jpg](/public/imported_attachments/1/client default gateway.jpg)
    ![client default gateway.jpg_thumb](/public/imported_attachments/1/client default gateway.jpg_thumb)



  • Yes, but what's about the LAN devices on clients side? Are these configured to use pfSense as theis default gateway?

    And you wrote above, you cannot ping from the server to the clients LAN. Did you try the ping from pfSense itself whith source = automatic?
    So cannot ping the clients LAN IP 192.168.8.1? And what's about the clients VPN IP 172.16.23.2?



  • @viragomann:

    Yes, but what's about the LAN devices on clients side? Are these configured to use pfSense as theis default gateway?

    Yes the lan client devices are configured with default gateway 192.168.8.1.

    @viragomann:

    And you wrote above, you cannot ping from the server to the clients LAN. Did you try the ping from pfSense itself whith source = automatic?
    So cannot ping the clients LAN IP 192.168.8.1? And what's about the clients VPN IP 172.16.23.2?

    About this table I am attaching two screen shoot. The first is the server ping (no answer) to client gateway, the second is the server ping with success the openvpn client.

    ![server ping client gateway.jpg](/public/imported_attachments/1/server ping client gateway.jpg)
    ![server ping client gateway.jpg_thumb](/public/imported_attachments/1/server ping client gateway.jpg_thumb)
    ![server ping client vpn.jpg](/public/imported_attachments/1/server ping client vpn.jpg)
    ![server ping client vpn.jpg_thumb](/public/imported_attachments/1/server ping client vpn.jpg_thumb)



  • I can't see any reason for that issue in the configuration.

    However, I've noticed that the ping responses seem to take a long time and be unstable. One take 200 ms, the other one more than 700, both is very long.
    What does the ping between server and client over WAN GW looks like?

    For troubleshooting the clients LAN not reachable issue, I would use Packet Capture from Diagnostic menu at pfSense client.



  • Thanks again for your precious help.

    @viragomann:

    I can't see any reason for that issue in the configuration.

    However, I've noticed that the ping responses seem to take a long time and be unstable. One take 200 ms, the other one more than 700, both is very long.
    What does the ping between server and client over WAN GW looks like?

    up wait time ping depends on the poor quality of ADSL in my area. When ping between server and client by the respective Wan ports have a similar result.

    @viragomann:

    For troubleshooting the clients LAN not reachable issue, I would use Packet Capture from Diagnostic menu at pfSense client.

    I send you attached the screen shoot of the Packet Capture Configuration and outcome.

    I also attach the image of the ping that I launched from the server.

    ![client packet capture.jpg](/public/imported_attachments/1/client packet capture.jpg)
    ![client packet capture.jpg_thumb](/public/imported_attachments/1/client packet capture.jpg_thumb)
    ![client packet capture2.jpg](/public/imported_attachments/1/client packet capture2.jpg)
    ![client packet capture2.jpg_thumb](/public/imported_attachments/1/client packet capture2.jpg_thumb)
    ![server ping for capture packet.jpg](/public/imported_attachments/1/server ping for capture packet.jpg)
    ![server ping for capture packet.jpg_thumb](/public/imported_attachments/1/server ping for capture packet.jpg_thumb)



  • Try to ping another LAN device and take a capture once on OpenVPN interface and once on LAN.



  • These are the results of what you asked for. I hope I have understood what you asked.

    attached images.

    ![client lan capture packet1.jpg_thumb](/public/imported_attachments/1/client lan capture packet1.jpg_thumb)
    ![client lan capture packet1.jpg](/public/imported_attachments/1/client lan capture packet1.jpg)
    ![client lan capture packet2.jpg](/public/imported_attachments/1/client lan capture packet2.jpg)
    ![client lan capture packet2.jpg_thumb](/public/imported_attachments/1/client lan capture packet2.jpg_thumb)
    ![client lan capture packet3.jpg](/public/imported_attachments/1/client lan capture packet3.jpg)
    ![client lan capture packet3.jpg_thumb](/public/imported_attachments/1/client lan capture packet3.jpg_thumb)
    ![client lan capture packet4.jpg](/public/imported_attachments/1/client lan capture packet4.jpg)
    ![client lan capture packet4.jpg_thumb](/public/imported_attachments/1/client lan capture packet4.jpg_thumb)
    ![client lan capture packet5.jpg](/public/imported_attachments/1/client lan capture packet5.jpg)
    ![client lan capture packet5.jpg_thumb](/public/imported_attachments/1/client lan capture packet5.jpg_thumb)



  • Please do the ping also to the LAN device when capturing at OpenVPN interface.



  • I also made the ping of the LAN device and the answer is the "client screenshoot lan capture packet2.jpg". I am attaching again. When ping from openvpn server (192.168.10.1) the LAN device (192.168.8.80) and I capture packets the result is the image I have attached and I am attaching again.

    ![client lan capture packet2.jpg](/public/imported_attachments/1/client lan capture packet2.jpg)
    ![client lan capture packet2.jpg_thumb](/public/imported_attachments/1/client lan capture packet2.jpg_thumb)



  • I did it again a packet capture of wan interface client.
    From openvpn server (192.168.10.1) to the device openvpn client (192.168.8.80).
    the result is "image1.jpg".
    If in Packet Capture I choose as "LAN" interface does not capture any packets. I'll spare you the blank image. Otherwise, if I want to capture the interface openvpn the result is in the picture that I previously you attached, that is, the "lan capture packet2.jpg" client. I hope I've been sufficiently clear.




  • The screenshot above "client lan capture packet4.jpg" in Reply #8 shows a capture of LAN, but there is too much noise at this interface. It would help to select only ICMP protocol.
    Also "client lan capture packet2.jpg" from OpenVPN interface only shows pings from the VPN server to the client. Obviously you have activated gateway monitoring on the servers VPN GW. You can it for troubleshooting or enter the destination IP 192.168.8.80 in packet capture at host address to filter for it.



  • Thanks again for your patience.

    I performed the following tests:

    1. capture of ICMP packets from the LAN interface of the OpenVPN client.
      Ping from openvpn server (192.168.10.1) to device lan openvpn client (192.168.8.80).
      Screenshot "config_lan1.jpg" and "test_lan2.jpg".

    2. capture of ICMP packets from WAN interface of the OpenVPN client.
      Ping from openvpn server (192.168.10.1) to device lan openvpn client (192.168.8.80).
      Screenshot "config_wan1.jpg" and "test_wan2.jpg".

    3. capture of ICMP packets from OPENVPN  interface of the OpenVPN client.
      Ping from openvpn server (192.168.10.1) to device lan openvpn client (192.168.8.80).
      Screenshot "config_ovpn1.jpg" and "test_ovpn2.jpg".

    Yes, I have activated gateway monitoring on the servers VPN GW. Attaching a picture of the setup. "Gateway monitoring.jpg".













    ![gateway monitoring.jpg](/public/imported_attachments/1/gateway monitoring.jpg)
    ![gateway monitoring.jpg_thumb](/public/imported_attachments/1/gateway monitoring.jpg_thumb)



  • @ccrr10:

    Yes, I have activated gateway monitoring on the servers VPN GW. Attaching a picture of the setup. "Gateway monitoring.jpg".

    So filtering for the host address 192.168.8.80 in packet capture would supress the display of the monitoring pings.

    If there gets nothing to the client it must be a routing issue at server, but all the routes above look well.



  • Dear viragomann, now that the picture of the situation is clearer and we seem to have all the necessary information, I would like to think along with you and to anyone who wants to help me figure out this problem.
    When the openvpn server (192.168.10.1) launch a ping to a LAN device openvpn client (192.168.8.80) the Packet Capture set of client interface "openvpn_client" detects the ICMP packet (see "test_ovpn2.jpg"), but if the packet Capture client is set sull'intefaccia "lan" the ICMP packet is not detected, because on the LAN does not reach any ICMP packet.
    Now I ask: "What prevents the ICMP package to switch from IP 172.16.23.2 to IP 192.168.8.1 and then to IP 192.168.8.80?".
    Now you might think that it is a routing problem or a problem of firewall rules.
    If it was a routing issue I wonder: "why, if throwing a ping from the client (192.168.8.1) to the server (192.168.10.1), the packet is either the forward road that return? That is the package arrives at its destination and I have confirmation from the client.
    It could be a firewall rule. I think I gave fair rules to forward packets between the VPN and LAN. (see "lan client firewall.jpg")
    I make the question again: "what prevents the ICMP packets to arrive at its destination?".
    Please do one last effort. Thanks again. Sorry for my bad English.



  • @ccrr10:

    When the openvpn server (192.168.10.1) launch a ping to a LAN device openvpn client (192.168.8.80) the Packet Capture set of client interface "openvpn_client" detects the ICMP packet (see "test_ovpn2.jpg")

    This picture doesn't show the ping to 192.168.8.80, it only shows pings to 172.16.23.2, which is obviously initiated by gateway monitoring, as mentioned above.
    To get rid of this, deactivate GW monitoring or filter to the IP 192.168.8.80 in packet capture. Both I've already mentioned.

    @ccrr10:

    "What prevents the ICMP package to switch from IP 172.16.23.2 to IP 192.168.8.1 and then to IP 192.168.8.80?".

    Maybe a filter rule or a false routing. A feasible packet capture of ping requests from server side to a LAN device would bring some light in this, and I've asked for it days ago.
    If you can't see the pings on clients OpenVPN interface, test it on the servers OpenVPN interface, but there may be nothing also, so it would be a routing problem.
    If you see it on VPN interface, but not on clients LAN, it should be a filter issue at the client.

    It could be also a wrong firewall rule on clients OpenVPN interface. So post a sreenshot to verify.

    @ccrr10:

    If it was a routing issue I wonder: "why, if throwing a ping from the client (192.168.8.1) to the server (192.168.10.1), the packet is either the forward road that return? That is the package arrives at its destination and I have confirmation from the client.

    If you do this packet capture with source = automatic, it comes from 172.16.23.2 not from 192.168.8.1. So an routing issue for 192.168.8.0/24 on server side wouldn't matter.
    But you may select the source IP manually.

    @ccrr10:

    It could be a firewall rule. I think I gave fair rules to forward packets between the VPN and LAN. (see "lan client firewall.jpg")

    Rules on LAN interface take no effect here, you have to set your rules on OpenVPN interface, cause this is the one where packets come into the client.

    @ccrr10:

    Thanks again. Sorry for my bad English.

    Me as well, please.  ;)



  • I am testing openvpn for the first time myself. I encountered the same situation.  Connection established but no communication.

    What I found to be the problem:

    In order to make a route work ( me -> server -> client) , the client also needs to have a route back to the origin  (me <- server <- Client).  So I have to push routes to the client letting them reach my server Lans side (big no no).

    This is not what i understood from the tutorials.  I understood i would be able to access all vpn clients from the server side, but not have any clients be able to initiate connections to my servers lans.

    I expected the client vpn server to know where to find the source ip without having to expose my server lan side to the vpn.



  • viragomann, I deactivate GW monitoring and effectively when the server ping the device on the LAN Client not capture it any ICMP packet whatever the selected interface. I did not understand correctly.

    @viragomann:

    Maybe a filter rule or a false routing. A feasible packet capture of ping requests from server side to a LAN device would bring some light in this, and I've asked for it days ago.

    Excuse me but I did not understand what to do. Because I thought I did. I pinged from vpn server (192.168.10.1) to the LAN client device (192.168.8.80).

    I attach screenshot of the client openvpn firewall rule. (openvpn_client_firewall.jpg)

    @viragomann:

    If you do this packet capture with source = automatic, it comes from 172.16.23.2 not from 192.168.8.1.
    ….............
    But you may select the source IP manually.

    In fact, if I choose manually as LAN source I have no results. If I choose I OPENVPN_CLIENT response of ICMP packets from the server.

    @viragomann:

    …................................
    So an routing issue for 192.168.8.0/24 on server side wouldn't matter.
    ...................................

    I do not understand what you mean.

    What do you recommend I do?
    Thank you.




  • @ccrr10:

    In fact, if I choose manually as LAN source I have no results. If I choose I OPENVPN_CLIENT response of ICMP packets from the server.

    So if this is the case, the only type of firewall rule which could block this is a floating rule on vpn server with the Quick option checked and direction "out" or "any".  Do you have any floating rules there?

    If not, the pings are obviously not routed in the VPN on server and I can't see any reason for that.
    The only recommendation I can make for this case is to start from scratch. I've read here some posts, where guys had similar issues and didn't get it work. After re-installation of pfSense and set up the same configuration again manually it worked.
    Maybe it helps to delete the VPN server and set it up again.



  • I installed another openvpn server no site-to-site but for Windows PC users.
    I have the same problems I have highlighted in previous posts.
    The configurations are very similar. The difference is that now the openvpn client is a PC with S.O. Windows 7.
    From the client can ping the server, which as in the case of site-to-site vpn uses subnet dedicated to her (172.16.24.0/24).
    My observation is as if missing a link between the LAN and LAN client openvpn.
    My PC has an IP address 192.168.55.14, while the TAP adapter has an IP address 172.16.24.2.
    The OpenVPN server has an IP 172.16.24.1 and 192.168.10.1 Gateway.

    When my PC ping the gateway (192.168.10.1) the ICMP packet is not part of my LAN but by the IP 172.16.24.2 that is the IP of the TAP adapter. So when I want to ping from gateway (192.168.10.1) to my PC (192.168.55.14), the ICMP packet does not arrive on my LAN but stops the IP of vpn server (172.16.24.1).

    I did some tests:

    I captured the ICMP packets addressed to vpn server from my PC 192.168.55.14 -> 192.168.10.1

    1. Interface LAN does not capture packets.
    2. Interface OPENVPN_SERVER_PC (screenshot capture_1.jpg).

    I captured the ICMP packets addressed to my PC from vpn server 192.168.10.1 -> 192.168.55.14

    1. Interface LAN does not capture packets.
    2. Interface OPENVPN_SERVER_PC (screenshot capture_2.jpg).

    The routing table of the gateway is as follows. (screenshot Routes.jpg).

    In the routing table it can be seen that the route for the 192.168.55.0/24 LAN is through ovpns2 which is on the side 172.16.24.1 server and client172.16.24.2 side.
    Now the tests show that the parties ICMP packets from the server (capture_2.jpg) leave from the vpn server 172.16.24.1 and are addressed to my PC 192.168.55.14.

    I captured these packets sent from the vpn server destined to my PC with Wireshark interface TAP adapter and it shows how packets do not arrive IP 172.16.24.2. (Wireshark_1.jpg).
    Of course the same thing happens if I capture the packets on the LAN interface. (Wireshark_2.jpg).

    My question is: "because the ICMP started from vpn server destined to vpn client packages (my PC in this case) stop on the interface of 172.16.24.1 vpn server and are not routed on the other vpn interface. 172.16. 24.2 and then even the IP of 192.168.55.14 PC having the routing table defined the way forward? ".

    I attach a screenshot of the routing table of my PC 192.168.55.14 (routes_PC.jpg)

    I state that my PC firewall has been disabled.

    I attach a screenshot of the LAN and the firewall rules servervpn (firewall_1.jpg) and (firewall_2.jpg)

    Thanks to anyone who can help me understand, and special thanks to viragomann that has had great patience with me.

















  • Netgate

    You are trying to route to other networks on the client side and connect using OpenVPN client on one of the windows hosts there?

    Basically a site-to-site connection but using the OpenVPN windows client not OpenVPN on another pfSense?

    I don't know if the windows client will do that.



  • Derelict,
    thank you for your answer,

    @Derelict:

    You are trying to route to other networks on the client side and connect using OpenVPN client on one of the windows hosts there?
    Basically a site-to-site connection but using the OpenVPN windows client not OpenVPN on another pfSense?

    No. I'm trying to understand why after a OpenVPN connection, it is site-to-site or both Windows client userit is not possible (at least for me) to communicate between the two networks: 192.168.10.0/24 LAN and LAN servers 192.168.8.0/24 client (in the case of site-to-site). I posted several screenshots where I highlighted the problem, highlighting the route table and the roles of the firewall. Within these configurations there is (in my opinion) nothing that should hinder communication. I ask the community to pfSense if there is something which I am not aware to run this communication between each network.



  • In advanced configuration "custom options" did you push the routes that the client should reach on your side?

    push "route 10.10.20.0 255.255.255.0";

    I found the process to fail when using the standard routing fields openvpn profides.  But using custom options it just worked

    route  10.0.0.1 255.255.255.0    -> subnet that exists on the client side
    push "route 10.10.1.1 255.255.255.0"  -> subnet that existis on my side that the client can reach.

    If the client can ping you, then both routes are working I guess. If the forward route and return route didn't exist on either side, the client would never receive the ping response.  Sorry I can't help further.


  • Netgate

    Just use Local Networks. No need to mess about with custom options. Look a the generated config. It just pushes the same networks.



  • personally i had no luck with local networks following neither the pfsense book or wikis on google.  Custom options though, worked like snapping my fingers.  route this push that. It was just a thought, but as for the first post description, if he can receive ping requests from one side it implies routes are properly done and something else is missing.


  • Netgate

    Firewall rules on either the destination firewall's OpenVPN tab or, more likely, on the destination host itself.



  • Thank you very much for your answers. Thanks for your help.
    I also had the impression that it is the firewall rules that prevent communication between the two lan through the vpn connection. I thought I had correctly set the rules, but apparently it does not.


  • Netgate

    Post the rules you think were correct and check any local firewall (think windows firewall) on the destination host.



  • What interests me is the OpenVPN connection site-to-site. In fact I attach firewall configurations of both the server (192.168.10.1) that the client (192.168.8.1).

    ![lan server firewall.jpg](/public/imported_attachments/1/lan server firewall.jpg)
    ![lan server firewall.jpg_thumb](/public/imported_attachments/1/lan server firewall.jpg_thumb)
    ![lan client firewall.jpg](/public/imported_attachments/1/lan client firewall.jpg)
    ![lan client firewall.jpg_thumb](/public/imported_attachments/1/lan client firewall.jpg_thumb)