Best Setup?



  • I want to set up a VPN between my home and my mom's home - share server access, etc.

    I've played around with OpenVPN and the connection looks like it's set up properly on each side, but I can't see either side from… well... either side.

    Firewall ports are forwarded for origination (to 1194) and everything looks OK - maybe I need someone to double check my work.

    This is the network setup

    My Network: 10.6.4.0/24
    Her network:  10.7.7.0/24

    The OVPN is set up and is using 10.0.8.0/24 as instructed (I also toyed with another setting, but went back to this one just to be in line with documentation.

    Problem is, either side can only ping its respective host (i.e. the server can ping 10.0.8.1 and the client can ping 10.0.8.2) and not the opposing network, even if I add a route to the advanced box on the OVPN connection setup.

    Where can I go from this point?

    The Firewall/NAT rules are set up like this:

    Server:  WAN UDP * * WAN address 1194 (OpenVPN) 10.6.4.111 1194 (OpenVPN) OpenVPN to Mom
    Remote: WAN UDP * * WAN address 1194 (OpenVPN) 10.7.7.1 1194 (OpenVPN) OpenVPN

    The Server is my copy, remote is hers.

    Both sides are running pfsense 2.0.1-RELEASE (amd64)

    What'd I foul up?   ???

    Edit - I'm using a shared key setup.  I generated it from the server, and pasted it on the client.





  • Why do you have a port forward there? Most always don't want or need that for your OpenVPN client or server. I'd expect that to break your connectivity entirely, but maybe the connection established before the port forward(s) were there so it'll continue working until the client's IP changes or the client restarts. Sounds like it is functional but not routing, so you're likely missing the "remote network" field on one or both sides.



  • @Indigo64:

    I used this guide.  This guide is useless.

    http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_(Shared_Key,_2.0)

    That guide is 100% accurate.



  • Sorry, no, it's not 100% accurate - if it were 100% accurate, then it would repeatable results for both myself and a coworker (who just admitted in IRC a few minutes ago that it also didn't work for him)

    For the record, I tried it with and without the firewall settings - I included them in the post because I wanted to show that I had tried them.



  • Got a little further by adding quotes around the routes in the advanced boxes, but still no connectivity on either side.  (and also rebooted both pfsense boxes)

    I'm also getting that error page on the VPN status page, but a post I found on the forums here says that it's normal for this type of connection to say this?

    I'm not sure what to do here.  I've followed that guide about four times tonight alone - recreating, re-doing…  it just flat out doesn't work.  And I'm not doing anything overcomplicated with multiple sites, I just want two sites to be able to talk to each other!




  • Out of frustration, I took the quotes off of the routes in the advanced box AND removed the semicolon.  BOOM connection.

    You guys may want to edit the guide.  That was bull$___.  This is my first attempt to try it and the "100% correct" guide was wrong about something.

    I just ran a test - put the ; back into the advanced box, kills the connection.  Take it out, it comes back online.  >:(



  • It's correct, I read through it again to verify. I've only done about 500 of these (seriously). The ; has no impact on the config aside from being a new line, whether or not it's there if you have just a single custom option has no relevance. If you have multiple routes, you'll create an invalid config without the ;. If you're duplicating the route where you shouldn't be, that could cause problems, your OpenVPN log would show why.



  • So why is that now just one side is working (the client side) and not the host?  I can see the host network from the client, but not vice versa.  I've read that how to four times tonight… I've made sure every step was done EXACTLY as it said.

    What did I miss from the infallible document?



  • Probably "To filter incoming traffic across the VPN, add rules to the OpenVPN tab under Firewall > Rules" - missing rules on one side.



  • @cmb:

    Why do you have a port forward there? Most always don't want or need that for your OpenVPN client or server. I'd expect that to break your connectivity entirely, but maybe the connection established before the port forward(s) were there so it'll continue working until the client's IP changes or the client restarts. Sounds like it is functional but not routing, so you're likely missing the "remote network" field on one or both sides.

    So now you're telling me that I should have port forwards?  Make up your mind.  :P



  • Second most likely cause (and the almost certain cause if you can ping the LAN IP on the remote side) is a host firewall on the client you're trying to reach.



  • Port forwards are not firewall rules. It says Firewall>Rules, not Firewall>NAT. The problem with the document appears to be your reading comprehension.



  • Yes, I hopped on that one too fast.  Sorry.

    I just checked, both of them have the requisite rules for their respective access to the OpenVPN connection.

    The remote "client" pfsense network can ping my host network, but I still cannot ping (or access) anything on the client network (nor can I ping its pfsense host)

    There are also no firewalls enabled on the other side for the test clients at this time.



  • Nevermind.  Got it sorted.

    To get it working on both sides, and feel free to correct me if I made a mistake here…

    On Firewall > Rules:  WAN Tab:

    UDP  10.0.8.0/24  *    *  *  *    None

    On Firewall > Rules: OpenVPN Tab:

    *    *  *    *    *    *    None

    Applied to both sides, everything is pingable.

    I do notice that there's some pretty bad latency, so I'm not sure if this setup is invalid, or if it's just the DSL being...  well, DSL.



  • Ugh this system setup is SO FRUSTRATING.

    I disabled the VPN link to see if there was a problem with the DSL (there was) but I brought it back up once the problem was resolved, but getting the connection back is akin to asking the impossible.

    Even after 45+ minutes, there's still no link up.  As you can see from above, it WAS working fine… why won't the link activate again?  NOTHING has changed, and stopping/restarting the service doesn't do anything.

    Why is this solution so difficult?  I use OpenVPN with Untangle for work and it's never been this hard to work with.



  • Removed & re-created the VPN using the same instructions/setup as before.

    OH WHAT DO YOU KNOW?!?!!

    Still. Does. Not. Work.



  • Followed this word for word.  Compared screenshots to my own views.

    Guess what?

    Still doesn't work.

    http://blog.stefcho.eu/?p=576



  • One thing that is odd/possibly confusing to readers, on the "stefcho" blog is:

    Server host or address, enter the WAN IP address on the first router pfSense01, in our case 10.10.2.2. Server port, whatever port you have used on the server, in our case the default 1194.

    It looks like he his demo is on a completely private test setup, not over the real internet. His pfSense01 has a WAN IP address of 10.10.2.2 - so I guess he connected 2 pfSense WANs to a switch at home, then made an OpenVPN across the switch between the LANs of the 2 pfSense boxes.
    In your post, I can't see any mention of the public IP of the server end. The client end needs to have the public IP of the server end.
    Also, I just leave the encryption algorithm at the default.
    Apart from that, the blog is what I do. I have a bunch of these site-to-site shared key links and they setup fine for me. Maybe there is something critical missing from the blog, but I didn't notice it.
    Post screen shots of the server and client OpenVPN settings (rub out the shared key value), firewall rules on the WAN and OpenVPN.



  • That blog post is correct as well. No, not everyone who's ever written a site to site OpenVPN guide is conspiring against you. They really do work as illustrated.

    My guess at this point is you have a general connectivity problem between client and server for some reason. Packet capture, check firewall states, for the outer 1194 or whatever port you picked.


Locked