Site to site on two pfsense
-
Hi all
Im sitting with the exact same problem and would just like to find out if the problem was fixed with help above and if so please share some details.Thanks
-
Please post server1.conf and client1.conf.
How are you trying to access your files?
-
Please post server1.conf and client1.conf.
How are you trying to access your files?
Hi marvosa
I had print screen the conf for both.
From client site, just enter server site of File Server IP. I cannot ping the server tunnel IP as well.
-
I had print screen the conf for both.
I'm not sure what that means, but the files you need are located here:
/var/etc/openvpn/
You can use putty and log into to the shell or go to Diagnostics -> Edit File and post the contents of server1.conf from the server and client1.conf from the client.
-
Hi
Sorry for the long wait. Okay so my openvpn tunnel is up and i basically opened up everything that made sense to me for a local lan connection over the tunnel. I can ping both tunnel addresses(from server and client) and the local ip of each pfsense box. Each setup is connected to a windows laptop. My goal now would be to ping from the client side: windows laptop -> pfsense client -> vpn tunnel > pfsense server -> windows laptop (test purposes only, this will be replaced by a linux pc )
As soon as I can get it to ping I would like to get a second and third pfsense client(all in remote locations), each with their own local subnet to get access to the pfsense server local subnet.
My last step would be to add road warriors as well for about 3 clients that will run the Openvpn client software on their devices(Windows).
Here are my log files for my first server and client. For testing purposes my server is connected to my nat router and client to a mobile 3g router to simulate a remote connection
Server Config:
dev ovpns1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.2.15
ifconfig 10.0.9.1 10.0.9.2
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 192.168.1.0 255.255.255.0"
route 192.168.10.0 255.255.255.0
secret /var/etc/openvpn/server1.secretClient Config:
dev ovpnc1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.2.100
lport 0
management /var/etc/openvpn/client1.sock unix
remote dyndns address 1194
ifconfig 10.0.9.2 10.0.9.1
route 192.168.1.0 255.255.255.0
secret /var/etc/openvpn/client1.secretRegards and thanks for the reply thus far.
-
Try manually adding outbound NAT rules that force every packet departing from the LAN (either at Main site or at Branch site) to be NATed to the interface address.
Also try to diagnose routing via Diagnostics->Routes, checking that the OpenVPN settings do add routes to remote networks as configured.
Finally, try packet captures at different interfaces (ovpns1 & ovpnc1) to see how packets get routed.
-
I to am having issues with site to site.
I am able to successfully bring up tunnel, I can ping the LAN IP address from pfsense box 1 to pfsense box 2 and see traffic come across opvns1 interface in both directions.
but when a workstation pings either the LAN IP of the remote pfsense or any other remote IP on subnet it fails and I see no traffic cross the opvns1 interface. I have opened up FW rules to (* * * * *) on LAN and OPENVPN tabs so all traffic should flow unhindered.
So I gather that tunnel is up and available but something in routing has gone sour. Below are the routes I have for the tunnel.
Anyone else have out of the box issues that resemble this issue?
My site to site uses ovpns2 interface on box1 and ovpnc1 interface on box2
LAN subnets are 192.168.23.0/24 and 192.168.25.0/24
VPN link subnet is 192.168.16.0/24
-
I don't see any flaws in the routing tables (I assume you left out the default route definition though). Have you tried using manually defined outbound NAT?
-
Sorry for the delay, I was on vacation.
leyley - Are you going to post your configs or did you resolve your issue? I can see a few things right off the bat:
-
On the server-side, your local and remote networks are the same
-
On the client-side, the remote network overlaps the tunnel network, which leads into #3
-
Your client config suggests that your server-side LAN is 192.168.200.0/23, which conflicts with your tunnel network, so you will need to adjust your tunnel network accordingly.
28red - Did you get your issue resolved?
cubert - Still having issues? Post your server1.conf and client1.conf. Disable the software firewall on your clients. Make sure PFsense is the default gateway on your clients. Also, I see 192.168.23.0/24 is on a bridged interface (bridge0) … explain what you're doing there.
-
-
We have 2 PFSense w/wifi adaptors that we bridge the "Lan" and WIFI interfaces together as a single interface for internal traffic.
We had a IPSEC VPN up between the to systems that was running fine but needed to test out setting up a open VPN for a client so we started testing on our selves. We disabled the IPSec tunnels and brought up the OpenVPN tunnel.
Client.config
–---------------------------------------------------------
dev ovpnc1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp-client
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 173.166.143.121
lport 0
management /var/etc/openvpn/client1.sock unix
remote 71.43.130.170 1195
ifconfig 192.168.16.2 192.168.16.1
route 192.168.23.0 255.255.255.0
secret /var/etc/openvpn/client1.secretServer.conf
dev ovpns2
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp-server
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 71.43.130.170
ifconfig 192.168.16.1 192.168.16.2
lport 1195
management /var/etc/openvpn/server2.sock unix
max-clients 10
push "route 192.168.23.0 255.255.255.0"
route 192.168.25.0 255.255.255.0
secret /var/etc/openvpn/server2.secretI can ping from pfsenseA to pfsenseB (and reverse) through openVPN using these addresses ->192.168.16.1 192.168.16.2 and I can ping LAN/Bridge address from the other side on both systems. I just does not seem to route the Subnet addresses.
All LAN/Bridge and Openvpn firewall tabs are ***** across the board passing everything. Both systems are on the Internet with a static WAN IP address and are routing all traffic for the local subnets.
-
Configs look solid, nothing stands out, so it comes down to looking at logs and troubleshooting. A few things I would try:
-
what PFsense versions are both sides on?
-
I've read many posts that have stated rebooting both sides have solved weird routing issues… might be worth a shot if you haven't tried it already
-
Turn on logging on the openvpn, lan and bridge interface to see if you can catch something in the logs
-
check Status -> System Log -> OpenVPN are there any errors in there? Also check the IPsec tab and make sure some of that old IPsec tunnel isn't hanging around
-
I'm sure you've done this, but we'll put it out there anyway… once you turn on logging in your firewall rules, disable the windows firewall on both sides and start generating traffic... e.g. telnet to known open ports, RDP to something, etc... you may catch something in the logs (check both sides)
-
verify PFsense is the default gateway on your clients
-
Re-verify you have any/any rules on all your interfaces on both sides
-
I've also read posts where old IPsec settings were the culprit to routing issues, so backup your config, then delete all your IPsec info (both sides), then reset the states on both sides… you may have some old states from your IPsec tunnel
-
Just for Sh*ts and Giggles…. switch to UDP then try again
-
Just to rule out that bridge…. un-bridge that interface on the server-side, reset your states and try generating traffic again
-
Unfortunately, I've also read this has worked for others…. but as a last resort, blow away both sides and rebuild fresh on v2.1.... for whatever reason that has miraculously fixed issues also
-
-
Well… (feeling kinda stupid) :P
I got as far as step 2 and it started working like expected. I haven't had to reboot PFSense devices in ages and didn't occur to me. In my defense, they were also in production use so was not convenient at the time.
Problem solved IPSec had something left over after disabling tunnels that a reboot resolved.
Thanks Marvosa...