LAN computers can't reach computers behind OpenVPN Server



  • Hi,

    I've successfully setuped pfSense to connect as a client to an other OpenVPN server. But all my computers behind pfSense aren't able to ping other computers behind that OpenVPN server. But if I ssh to pfSense, I can ping them. Only clients on the LAN side who can't.

    Any idea?



  • Check your firewall rules, that might be getting you.
    RC



  • I've got exactly the same problem.

    my pfSense also connects to a OpenVPN Server as a Client.

    LAN Clients(A)  –-  pfSense  ---(Internet)---  OpenVPN Server  ---  LAN Clients(B)

    LAN Clients(A) 192.168.0.0/24
    LAN Clients(B) 192.168.200.0/24

    I'am able to ping LAN Clients(B) via the pfSense shell but i can't ping to a LAN Clients(B) from a LAN Client(A)

    I enabled Logging

    Act   Time   If   Source   Destination   Proto

    Aug 15 02:26:38 LAN 192.168.0.2 192.168.200.79 ICMP

    (The rule that triggered this action is:
    @58 pass in log quick on em0 inet from 192.168.0.0/24 to any flags S/SA keep state label "USER_RULE: Default LAN -> any")

    These are my temporary Firewall Rules for testing purposes:

    Firewall Rule (LAN):

    Proto   Source   Port   Destination   Port   Gateway   Schedule   Description

    • LAN net       *         *                    *         *                  Default LAN -> any

    Firewall Rule (WAN):

    Proto   Source   Port   Destination   Port   Gateway   Schedule   Description

    • *               *         *                    *         *                  Default allow all on WAN in VM

    Any Idea whats wrong with my configuration?



  • I will test this on the first of next week.  I had no issues ping back and forth. The last night I tested this.

    Rules I have:
    Proto Source Port Destination Port Gateway Schedule Description

    • LAN net   *  *              *    *                      Default LAN -> any

    • OpenVPN     *  *              *    *                      Cartersweb.Net OpenVPN

    My OpenVpn is .19.0/24 I can ping from that to my internal network and from my .14.0/24.  I can go from .14.0/24 to .19.0/24 with out trouble.  I will re-testing this on monday to make sure that it is working correctly.

    RC



  • I too have no problem with any of my routed OpenVPN tunnels. A few questions:

    1. Is the OpenVPN server pfSense or something else?
    2. Can LAN clients (B) ping LAN clients (A)?
    3. Post at least your OpenVPN client config, and if possible, the server config too.

    It sounds like it could be a routing issue; like maybe the server doesn't know how to route back to your LAN (A) subnet. THe reason it might work from the pfSense box itself is that the source address could be on the tunnel's subnet and not your LAN's.



  • Same problem here, pfSense shell can access machines on remote LAN, but local machines behind pfSense can't access the machines on the remote LAN

    Remote openvpn server is an old SUSE box.

    client config on my pfSense system looks like this:

    
    writepid /var/run/openvpn_client0.pid
    #user nobody
    #group nobody
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    dev tun
    proto udp
    cipher BF-CBC
    up /etc/rc.filter_configure
    down /etc/rc.filter_configure
    remote <remote-ip>1194
    client
    lport 1194
    ifconfig 192.168.1.2 192.168.1.1
    ca /var/etc/openvpn_client0.ca
    cert /var/etc/openvpn_client0.cert
    key /var/etc/openvpn_client0.key
    comp-lzo</remote-ip> 
    

    I currently have a linksys router with DD-WRT on it and when I setup the openvpn client on it to connect to the remote openvpn server, everything is working as expected.

    client config on the DD-WRT router:

    
    client
    dev tun
    proto udp
    remote <remote-ip>1194
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    tun-mtu 1500
    tun-mtu-extra 32
    mssfix 1450
    ca /tmp/openvpn/ca.crt
    cert /tmp/openvpn/client.crt
    key /tmp/openvpn/client.key
    comp-lzo</remote-ip> 
    

    Any help appreciated



  • The remote end point needs to have a route back to the local LAN over the vpn tunnel. The best way to add this route is to use the route -option in openvpn config file.



  • Thanks for your answer, but in that case it wouldn't work with the linksys router (DD-WRT) either.
    Now, in the meantime I did some more investigation and found this in the openvpn server logs:

    Aug 20 14:00:19 <server-name>openvpn[26185]: gds/<client-wan-ip>:21469 Need IPv6 code in mroute_extract_addr_from_packet
    Aug 20 14:03:01 <server-name>openvpn[26185]: gds/<client-wan-ip>:21469 MULTI: bad source address from client [192.168.1.98], packet dropped</client-wan-ip></server-name></client-wan-ip></server-name> 
    

    So apparently the server is receiving the real ip adres of the client which it doesn't like.

    This made me think that I should probably do some SNAT'ing in order to hide the clients ip address.
    And indeed, that's what the "route-up.sh" and "route-down.sh" scripts on my DD-WRT router seem to do:

    ~ # cat /tmp/openvpn/route-up.sh
    iptables -A POSTROUTING -t nat -o tun0 -j MASQUERADE
    ~ # cat /tmp/openvpn/route-down.sh .sh
    iptables -D POSTROUTING -t nat -o tun0 -j MASQUERADE
    
    

    Unfortunately I have no idea how to do this on the pfSense server



  • Hello Briantist,

    1. Is the OpenVPN server pfSense or something else?
    It is a OpenSuse Box runnig an OpenVPN Server

    2. Can LAN clients (B) ping LAN clients (A)?
    no they can't. And i would like to keep it that way.
    But i can Ping the IP that the OpenVPN Server has assigned to my pfSense box from LAN B.

    3. Post at least your OpenVPN client config, and if possible, the server config too.
    Authentication method: PKI

    
    client
    dev tun
    proto udp
    remote xx.xx.xx.xx 1194
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ca ca.crt
    cert test.crt
    key test.key
    cipher AES-256-CBC
    comp-lzo
    auth SHA1
    
    

    My Goal is that CLients on LAN A can Access Lan Clients B, but LAN Clients B shouldn't be able to have access to the Clients on LAN A.

    LAN A
    192.168.0.0/24
    LAN B
    192.168.200.0/24
    OenVPN LAN
    192.168.1.0/24

    My pfSense Box has got the IP Addresses 192.168.0.50 (LAN A Subnet) and 192.168.1.2 (OpenVPN Subnet) and the OPEN VPN Server 192.168.1.1 (OpenVPN Subnet)

    Let's say i would send a Ping fron LAN A to LAN B.
    LAN A Client 192.168.0.10 sends the Ping request to his Gateway 192.168.0.50(pfSense).
    Now the pfSense box should send the request via his OpenVPN Subnet IP 192.168.1.2
    The Client on LAN B recieves the Ping request and sends the Answer back to the IP 192.168.1.2
    Now my pfSense box should route the Ping back to the Client in LAN A.

    Is this possible?



  • @lufu:

    Hello Briantist,

    1. Is the OpenVPN server pfSense or something else?
    It is a OpenSuse Box runnig an OpenVPN Server

    2. Can LAN clients (B) ping LAN clients (A)?
    no they can't. And i would like to keep it that way.
    But i can Ping the IP that the OpenVPN Server has assigned to my pfSense box from LAN B.

    3. Post at least your OpenVPN client config, and if possible, the server config too.
    Authentication method: PKI

    
    client
    dev tun
    proto udp
    remote xx.xx.xx.xx 1194
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ca ca.crt
    cert test.crt
    key test.key
    cipher AES-256-CBC
    comp-lzo
    auth SHA1
    
    

    My Goal is that CLients on LAN A can Access Lan Clients B, but LAN Clients B shouldn't be able to have access to the Clients on LAN A.

    LAN A
    192.168.0.0/24
    LAN B
    192.168.200.0/24
    OenVPN LAN
    192.168.1.0/24

    My pfSense Box has got the IP Addresses 192.168.0.50 (LAN A Subnet) and 192.168.1.2 (OpenVPN Subnet) and the OPEN VPN Server 192.168.1.1 (OpenVPN Subnet)

    Let's say i would send a Ping fron LAN A to LAN B.
    1. LAN A Client 192.168.0.10 sends the Ping request to his Gateway 192.168.0.50(pfSense).
    2. Now the pfSense box should send the request via his OpenVPN Subnet IP 192.168.1.2
    3. The Client on LAN B recieves the Ping request and sends the Answer back to the IP 192.168.1.2
    4. Now my pfSense box should route the Ping back to the Client in LAN A.

    Is this possible?

    1. Consider this:  unless you've added a static route to your client on LAN A, it has no idea how to get to LAN B's subnet, so it sends it to its default gateway, which is 192.168.0.50. This is the correct and expected behavior.
    2. It should but if it doesn't have a route that tells it that it can get to LAN B's subnet by using the OVPN subnet, then the packet will not go across the VPN. Let's assume it does have this route.
    3. The client does not send the reply to 192.168.1.2, it sends it to the address of the client on LAN A (192.168.0.X), and it since it has no route to it, it sends it back to its default gateway, 192.168.200.1(?). If that machine has no route to get to 192.168.0.X, then the reply will never reach you even if the original echo request packet got through.
    4. If you get to this point, then yes that is what will happen.

    Focus on 2 and 3. Look at the routing tables on both your pfSense box and on your OpenSUSE box. I see a distinct lack of a route command within your OpenVPN client config. I don't even see the ifconfig directive unless you left it our on purpose. Anyway, in the client you should have something like:

    route 192.168.200.0 255.255.255.0

    The server would have something like:

    route 192.168.0.0 255.255.255.0

    I know you desire not to have LAN B be able to ping LAN A, but you can't do that correctly with routing. You would have to have a firewall blocking the traffic (currently it's kind of buggy to filter an OpenVPN interface in pfSense and it only works in 1.2.3; see other posts for info). First get it working where the traffic flows through; you can try to worry about blocking LAN B after that.



  • I think lufu and I want to do the same thing and as I mentioned in my posts above it IS possible to connect to a remote OpenVPN server
    without having to explicitly specify routes on the client.
    On my DD-WRT box this works out-of-the-box (and it even works as lufu wants it to: local LAN (openvpn client) can connect to remote LAN (openvpn server))

    The only issue I'm having is that I need to masquerade the ip addresses of the local clients, otherwise the server will drop the packages.
    But I have no clue how to do this in pfSense.

    So any help on this would be greatly appreciated.



  • @gds:

    I think lufu and I want to do the same thing and as I mentioned in my posts above it IS possible to connect to a remote OpenVPN server
    without having to explicitly specify routes on the client.
    On my DD-WRT box this works out-of-the-box (and it even works as lufu wants it to: local LAN (openvpn client) can connect to remote LAN (openvpn server))

    The only issue I'm having is that I need to masquerade the ip addresses of the local clients, otherwise the server will drop the packages.
    But I have no clue how to do this in pfSense.

    So any help on this would be greatly appreciated.

    You dont have to create routes on the clients.
    This is why you should add the commands

    in the client you should have something like:
    route 192.168.200.0 255.255.255.0
    The server would have something like:
    route 192.168.0.0 255.255.255.0

    To the OpenVPN-config, so OpenVPN adds the routes for you.

    I'm not sure how you imagine you would want to access an IP-range without ever telling the router where to send the traffic.
    NAT/masquerade wont help with this. You still need a known destination.



  • Sorry, I meant specifying a route option on the client, not creating a route on the client.

    But believe it or not, both DD-WRT and Tomato are able to connect to the openvpn server at the office without having to specify this on the client:

    in the client you should have something like:
    route 192.168.200.0 255.255.255.0
    

    And yes all clients on my home LAN can access the pc's on the corporate LAN through this openvpn tunnel.
    But the pc's on the corporate LAN can't access the pc's on my home LAN (which is what I want)

    So the openvpn server does a "push route", but not the client.

    For completeness, this is the config on the server:

    port 1194
    proto udp
    dev tun
    ca keys/ca.crt
    cert keys/office.crt
    key keys/office.key
    dh keys/dh1024.pem
    server 10.1.10.0 255.255.255.0
    push "route 10.0.10.0 255.255.255.0"
    ifconfig-pool-persist poolpersist.dat
    keepalive 120 900
    comp-lzo
    user nobody
    group nobody
    persist-key
    persist-tun
    status openvpn-status.log
    verb 4
    crl-verify /etc/openvpn/crl/crl.pem
    

    By masquerading the ip's from my home LAN, the openvpn server thinks he is talking to my router/firewall (DD-WRT, Tomato, whatever)
    instead of a client behind it.
    It's my home router/firewall who (should) redirects the received packages to the corresponding client on the LAN.
    Or at least that's my understanding of it.

    But as I said I have no idea how I can set up this masquerading on pfsense.
    Or in other words, how can I specify SNAT rules on pfSense ?



  • Firewall –> NAT --> Outbound.
    But you can currently only specify "real" interfaces.

    I'm not sure if with the changes to allow firewalling of the OpenVPN interface it's now possible to NAT into the tunnel as well.
    What you can try:

    Disable auto-added VPN rules option - added to System -> Advanced to prevent the addition of auto-added VPN rules for PPTP, IPsec, and OpenVPN tun/tap interfaces. Allows filtering of OpenVPN client-initiated traffic when tun/tap interfaces are assigned as an OPT.

    • Add the OPT interface for OpenVPN.
    • Now enable under Firewall –> NAT --> Outbound "manual outbound NAT" and create a new rule.
    • When you create the new rule you should now be able to select as "interface" the OPT interface which represents the virtual OpenVPN tunnel.

    I dont know if this really works.
    In current versions it's not possible to select the OpenVPN interface for manual NAT.
    But worth a try ;)



  • That's what I was afraid for, no SNAT'ing on the vpn interface.

    Thanks for the tip on trying v1.2.3, but how stable is this v1.2.3 ?
    I already switched my entire LAN to pfSense, so I don't want to take any unnecessary risks by upgrading
    to an unstable version and/or creating some experimental rules ;)



  • 1.2.3 is currently an RC.
    Most people can run the RCs with absolutely no problems.

    @http://forum.pfsense.org/index.php/topic:

    Usually the best thing is to watch http://redmine.pfsense.org and http://rcs.pfsense.org if you want to watch things in detail.

    Interresting to look:
    https://rcs.pfsense.org/projects/pfsense
    https://rcs.pfsense.org/projects/pfsense/repos/mainline/logs/RELENG_1_2



  • thanks for the pointers.

    I'm still undecided, but probably I'll set up a vmware image with the latest v1.2.3 and use that as a testing platform for the openvpn stuff…



  • Don't know why I didn't found this before, but I just stumbled upon this post, which describes a temporary workaround (see edit at the end):
    http://forum.pfsense.org/index.php/topic,6341.msg36590.html#msg36590

    Adding that rule after having established the openvpn connection does make it work,
    but as soon as you reboot or even restart the openvpn connection, the rule is gone again.

    Therefore I opened the file /etc/inc/filter.inc in an editor and added the following 2 lines at the end of the function "filter_nat_rules_generate()":

    $natrules .= "\n# Custom NAT rule required for OpenVPN client connection\n";
    $natrules .= "nat on tun0 from 192.168.1.0/24 to any -> (tun0)\n";
    
    

    I know this is probably not supported  ::) , but it does seem to do the job for now…  8)



  • @gds:

    Don't know why I didn't found this before, but I just stumbled upon this post, which describes a temporary workaround (see edit at the end):
    http://forum.pfsense.org/index.php/topic,6341.msg36590.html#msg36590

    Adding that rule after having established the openvpn connection does make it work,
    but as soon as you reboot or even restart the openvpn connection, the rule is gone again.

    Therefore I opened the file /etc/inc/filter.inc in an editor and added the following 2 lines at the end of the function "filter_nat_rules_generate()":

    $natrules .= "\n# Custom NAT rule required for OpenVPN client connection\n";
    $natrules .= "nat on tun0 from 192.168.1.0/24 to any -> (tun0)\n";
    
    

    I know this is probably not supported  ::) , but it does seem to do the job for now…  8)

    I don't see this function in /etc/inc/filter.inc running 1.2.3-RC1. I also need NAT on tun0. I need a way to automatically add this rule. Why did they bother putting an OpenVPN client in pfSense if they weren't going to run NAT on it?



  • Okay, Reply #13 was very helpful. I added tun0 as OPT1 and then added an outbound NAT entry and now LAN traffic is able to go out the OpenVPN client.

    Thanks GruensFroeschli for that tip.


Log in to reply