PSK OpenVPN setup, but routing not quite working right. Any ideas?



  • I have 2.3.2 talking to an SG-1000 I just picked up as well, and trying to get a VPN going with a dynamic IP on the client SG1000 side.

    I have the following IP  arrangement:

    PFsense box A (server):

    LAN:  10.3.0.2  (10.3.0.0/16)
    Tunnel:  192.0.0.1  (192.0.0.0/24)

    PFsense box B (sg1000 client):

    LAN: 10.4.0.1  (10.4.0.0/16)
    Tunnel: 192.0.0.2  (192.0.0.0/24)

    I have a PC on 10.3.0.11 on Lan-A, and I have a PC on 10.4.0.10 on Lan-B.

    If sitting on the PC on Lan-A I ping the local PFsense box on 192.0.0.1 I can reach it.
    I can also ping the remote PCsense box across the tunnel on 192.0.0.2 just fine.
    If I try and ping 10.4.0.1 which is the remote LAN side of PFsense box, it fails, or if I try and ping the remote PC on 10.4.0.10 it fails.

    Now to me at least on the strange side, if I am on the PFsense box for Lan-A, I can use diagnostic ping, and ping both 10.4.0.1 and 10.4.0.10 on the remote LAN.  So just stuff only sitting in the local LAN can't reach the remote end.

    My first thought is routing, but looking at routes I see routes for the remote LAN's on both sides.

    I see 10.4.0.0/16 as a destination, and it points to 192.0.0.2
    I see 192.0.0.2 (and .1) show link#11 as the gateway, and Netif is ovpns1 on all.

    I have documented the one direction, but it's the same both ways, devices on 10.3.0.0 can't reach 10.4.0.0, or the other way around.  Looking at the firewall logs, I don't see any rejects, and in the rules for OpenVPN I have an allow all on both sides.

    Any ideas what I might be missing here??

    -Howard


  • Rebel Alliance Developer Netgate

    Not enough info there to say. It could be routing, traffic could be hitting a policy routing rule, remote side could be blocking…

    To start, post your OpenVPN configs (at least the remote networks), routing table contents, and LAN firewall rules on both sides



  • Not trying to play stupid, but I am quite new to PFsense, and OpenVPN.  I have been using Cisco ASA's and IPsec for ages, so I got the IPsec side of PFsense right up.

    What files on the drive am I looking for the info you requested?

    I see a /var/etc/openvpn/server1.conf

    Is this it?  More than happy to post any desired info while I have this on the bench, but I just need to make sure I am getting what you requested..

    Thanks…


  • Rebel Alliance Developer Netgate

    The settings from the GUI page are fine, no need to use the shell or dig at files/commands.

    VPN > OpenVPN, server/client, take a screencap of the settings including the remote network(s) (but not the keys, of course)
    Diagnostics > Routes for the routing table
    Firewall > Rules, LAN tab and take a screenshot of the LAN rules.



  • OK, key deleted as mentioned, but it is there, and the VPN does establish.

    The following are the images, starting with the server side, then the client side..















  • Rebel Alliance Developer Netgate

    That all looks OK.
    One thing I forgot to ask for: What are the rules on the OpenVPN tab on either side?



  • I have a pile of IPsec sessions working, stunned OpenVPN is beating me up on this one..

    Here are the server and client side openvpn caps:






  • FYI, and here is what I am seeing, this is a PC on 10.3.1.126, trying to ping across to the 10.4.0.0 remote LAN.  I can get to the local tunnel side, and the remote tunnel side, but not the remote LAN

    Here is just trying to ping the LAN side of the remote side.

    Lastly, here is inside of the local PFsense using Diagnostics -> Ping, so you can see the remote side is accessible.








  • Just a bump, and does anyone have any ideas, or am I just boned..



  • Nothing obvious jumps out at me unfortunately.

    Any time I've had an OpenVPN tunnel blocking in one direction but not the other it's been a firewall rule issue on one of the two pfSense boxes or a firewall in one of the endpoint devices (you're not hitting a Windows firewall issue?)

    The only other thing different I see from my typical setups is the use of PSK, I typically use PKI.

    Perhaps you could try to rebuild the link with defined certificates for the server and client?

    Might be worth a shot to try something different instead of banging your head against the same thing expecting different results (been there…...)


Log in to reply