Breaking my nuts 6 hrs on Site to Site VPN: doesn't work :-(
-
Good evening ;D
't Doesn't work ( :'( ).
I've followed the wiki pages to setup site to site VPN using a shared key (and a very short, but very helpful, sentence from a very nice member here :-* ).
Server: 192.168.2.0/24 (connected to cable. Since this is semi-static I've created a freeDNS name and added that to the client as the target host).
Client: 192.168.3.0/24 (connected to dsl).
Tunnel: 172.16.0.0/24I've added the general - as well as the OpenVPN - firewall rules on client and server.
I've restarted the OpenVPN-services around 25 billion times, and rebooted both pfSense machines. Nothing. The GUI shows both client and server as down.
(For completeness: so server was on its own switch, with CABLE, and laptop1 connected to it. Client was on its own switch too, with DSL, and laptop2 connected to it. So as far as both pfsense machines should be concerned they were not in the same room, but connecting cable <-> dsl).
And now for some weirdness:
1. Server: I can ping both the tunnel (172.16.0.1) and the FreeDNS name just fine from laptop 1.
2. Client: I can neither ping the tunnel (172.16.0.1) nor the FreeDNS name from laptop 2. I can however ping for example www.google.com, www.sap.com, etc.
3. I have attached the logs of both machines (verbosity 11).
3.A. Apparently, in System/General the ovpnc3 interface is constantly restarting.
3.B. The client apparently finds the server fine: [AF_INET]A.A.A.A:33333. I don't see any other complaints, although 'something' about MSS.
3.C. The server complains about: TCP/UDP: No outgoing address to send packet which doesn't give much in Google (1 post on this forum, no solution).I have triple checked all setups, created client and server again, made sure the key was pasted correctly, made sure server and client are setup on the correct WAN, double checked all firewall rules, disabled Snort and pfBlockerNG: I don't know what to do anymore.
Could anybody please help me? I'm so depressed after 6 hours :'(
Thank you very much in advance,
-
Did you add a firewall rule to the server-side WAN to allow that traffic through?
Are you certain both sides are using the same shared key? (Doesn't matter which side generated it, so long as you copy/paste the key from one to the other)
And the logs might be a bit too verbose. Try knocking it down to 3 or 4 and see what shows up there.
Also, check the Interface setting on the server side, should be set to 'WAN' and that WAN should also have a default gateway set.
-
-
Post your server1.conf and client1.conf.
-
I've added the general - as well as the OpenVPN - firewall rules on client and server.
What does this mean? Please post the firewall rules you've configured on both sides.
-
-
Change tunnel from Tunnel: 172.16.0.0/24 to Tunnel: 172.16.0.0/30
Br,M
-
Thank you all for your comments :-*
It works.It turns out there is problem with the compression, some error about 42 bytes. I disabled compression on server and client et voila: it works ;D
Thank you again.
Now a new problem, a new thread: a clean install of pfSense 2.3.4 and a restore of the config back: it hangs with all kinds of vague error messages.
-
They might be vague to you. They are a complete mystery to us.
-
I think it was:
Bad LZO decompression header byte: 42
I can't check the log anymore since I've reistalled and am trying to find out why a simple config restore doesn't work_._
-
I have two follow up questions:
1. Is this setup (the user BThunderW, halfway) better? https://forums.servethehome.com/index.php?threads/pfsense-site-to-site-vpn-connected-but-traffic-not-passing.5534/
2. How can I restrict access to the WAN-server port for only my remote client? Say my remote client has a dynamic DNS, can I add that as source in the WAN-firewall rule and also in the OpenVPN-firewall rule?
Thank you :)
-
@Mr.:
I have two follow up questions:
1. Is this setup (the user BThunderW, halfway) better? https://forums.servethehome.com/index.php?threads/pfsense-site-to-site-vpn-connected-but-traffic-not-passing.5534/
Better than what? Just follow this: https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site
2. How can I restrict access to the WAN-server port for only my remote client? Say my remote client has a dynamic DNS, can I add that as source in the WAN-firewall rule and also in the OpenVPN-firewall rule?
Connections in from WAN will be from the WAN address of the client. If you want to use that in a firewall rule allowing access you need to set dyndns on the dynamic client, create a host alias using that FQDN, and pass traffic sourced from that.
Connections from OpenVPN will be from the OpenVPN tunnel network or remote network address, not the dynamic WAN. Most people aren't very concerned since those are "inside" networks and users. If you are concerned about that we'd need more information about which VPN users should and which VPN users should not be able to access the webgui.
-
@Mr.:
I have two follow up questions:
1. Is this setup (the user BThunderW, halfway) better? https://forums.servethehome.com/index.php?threads/pfsense-site-to-site-vpn-connected-but-traffic-not-passing.5534/
Better than what? Just follow this: https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site
2. How can I restrict access to the WAN-server port for only my remote client? Say my remote client has a dynamic DNS, can I add that as source in the WAN-firewall rule and also in the OpenVPN-firewall rule?
Connections in from WAN will be from the WAN address of the client. If you want to use that in a firewall rule allowing access you need to set dyndns on the dynamic client, create a host alias using that FQDN, and pass traffic sourced from that.
Connections from OpenVPN will be from the OpenVPN tunnel network or remote network address, not the dynamic WAN. Most people aren't very concerned since those are "inside" networks and users. If you are concerned about that we'd need more information about which VPN users should and which VPN users should not be able to access the webgui.
Thank you Derelict ;D
1. I did follow the link you posted, but I want to know if the other one is better, from a security/'do the right thing'-perspective.
2. I have 4 Synologies that need to back up to a co-location, where we have another big Synology. I am very 'freaky' about security, because I have a OpenVPN rule open on WAN/WAN2 to allow incoming access. The more I can close things down the better it is. So hence my question if I can restrict the sources that can connect to the VPN-server: I want it to be only our remote co-location. You are saying that should be possible, so I am going to try it :)
Thank you :)
-
Come to think of it: would it be possible to run a second VPN-connection inside the pfSense tunnel?
Because Synology also has VPN, so would it be possible to use the Synology VPN-certificate-technology inside the pfSense tunnel?
That way nobody should be able to connect to the Synology (inside the pfSense VPN tunnel) if they don't have the Synology VPN certificate.
Or am I asking for impossible things now?
Thank you ;D
-
Why on Earth would you want to do a tunnel inside a tunnel?
Of course you can restrict connections on the server side to specific source addresses. It is a pass rule like any other.
Really hard to tell what you're doing wrong. Setting up shared key OpenVPN is pretty drop-dead easy.
-
Why on Earth would you want to do a tunnel inside a tunnel?
Making it more difficult for hackers, as they then need to hack two tunnels, needing more than one possible vulnerability?
(One pfSense/FreeBSD, one Synology/Linux).
It's sort of my safe at home: if you passed the first door, you meet a second door ;D
-
Really hard to tell what you're doing wrong. Setting up shared key OpenVPN is pretty drop-dead easy.
It already works, mine now was a follow up question.
(The problem was the 42 byte compression stuff that didn't make it work, I disabled compression and site to site works, I think I reported this back already?)
-
And I still would like to know, 'from an academic point of view', if this setup is better:
https://forums.servethehome.com/index.php?threads/pfsense-site-to-site-vpn-connected-but-traffic-not-passing.5534/
-
Is what about what better than what?
