Best Setup?
-
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.