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