Help getting OpenVPN session working..
I have a current PFsense 2.3 running on an Intel server, and then I went out and picked up an SG-1000 to try and put up a VPN between my two houses. The PFsense devices seem to be working great, but for the life of me I can't completely get the OpenVPN session to allow the two LAN's to communicate.
Here is what I have setup to test currently:
PC (10.3.1.126/16) <–> PFsense-A (10.3.0.2/16) <--Internet--> PFsense-B (10.4.0.1/16) <--> PC (10.4.0.11/16)
The tunnel is 172.30.1.0/24, with 172.30.1.1 on A, and 172.30.1.2 on B.
The sessions show as up, if I am on either PFsense device and use Diag/Ping, I can ping any of the above listed IP's just fine, so that proves the tunnel is live. I have also made sure for firewall rules that I have just put in permit any protocol, ALL on both LAN and OpenVPN to make sure the rules were not the hangup.
The problem is when I take and try and ping from one PC to the other, or to the LAN interface of the remote PFsense server, it doesn't work. So if 10.3.1.126 tries to ping 10.4.0.1 or 10.4.0.11 it fails. Also the same from the other side, if 10.4.0.11 tries to ping 10.3.0.2 or 10.3.1.126 it fails.
Looking at the OpenVPN log it looks like it is starting up and pushing the right routes OK on both sides of the links, and looking at the routing take, it also looks correct. So I am at a bit of a loss as to why this isn't working. I have probably a half dozen IPsec sessions running on the PFsense-A server without any issues at all, but need to use OpenVPN for the other house as it's on a dynamic IP, and I need to reach a static IP block in use at the remote location.
Any help in getting this sorted out would really be appreciated...
Post your server1.conf and client1.conf.
Here is my server1.conf:
dev ovpns1 verb 4 dev-type tun 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-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 188.8.131.52 engine cryptodev tls-server server 172.30.1.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc/server1 ifconfig 172.30.1.1 172.30.1.2 tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'hurlock-fw.leadmon.net' 1" lport 1194 management /var/etc/openvpn/server1.sock unix push "route 10.3.0.0 255.255.0.0" route 10.4.0.0 255.255.0.0 ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024 tls-auth /var/etc/openvpn/server1.tls-auth 0 persist-remote-ip float topology subnet
Here is my client1.conf:
dev ovpnc1 verb 4 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 udp4 cipher AES-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 184.108.40.206 tls-client client lport 0 management /var/etc/openvpn/client1.sock unix remote 220.127.116.11 1194 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key tls-auth /var/etc/openvpn/client1.tls-auth 1 ncp-disable resolv-retry infinite
If you need anything else let me know, as for sure I am scratching my head, as I wear the routing table looks right, but am sure I am missing something..
How about the usual check on Window PC's for a firewall rule blocking access to an "unknown" (the Remote LAN) network?
Have you tried temporarily disabling the Windows firewalls?
Did you also add a Client Specific Option on the OVPN Server to specify that 10.4.0.0/24 should be "iroute'd" for the Client?
Thanks for the input, and yes the windows firewall is disabled. In fact I also tried it from a Cisco switch on the network, as well as a Raspi box running linux as well., same issue. Also note that I can actually ping the devices from inside the firewall, so they are pingable, just not from LAN to LAN.
I just went back and double checked, but I do have 10.4.0.0/16 in the client options for that connection, so yes that is present. Happy to post snaps of the routing tables or options needed.
After recreating your configs, the client-side is missing a couple config lines, so the issue is on the client side.
The client-side has not defined a tunnel network and there is no route statement for site A's LAN.
On the client-side, enter the following:
IPv4 Tunnel Network = 172.30.1.0/24
IPv4 Remote network(s) = 10.3.0.0/16
After bouncing the tunnel, you should be good to go.
Thanks for trying to help, and I believe I have done as you requested, but am still seeing the same issue. I went into the client VPN and added the networks to the configs per your direction, and my client config now shows:
dev ovpnc1 verb 4 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 udp4 cipher AES-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 18.104.22.168 tls-client client lport 0 management /var/etc/openvpn/client1.sock unix remote 22.214.171.124 1194 ifconfig 172.30.1.2 172.30.1.1 route 10.3.0.0 255.255.0.0 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key tls-auth /var/etc/openvpn/client1.tls-auth 1 ncp-disable resolv-retry infinite topology subnet
Is this what you would have expected to see changes wise, or did I miss something?
Also to eliminate the issue being a PC, I ran the last set of pings that was on a Cisco switch at the IP of 10.3.0.3, and it's default gateway points to the 10.3.0.2 IP that is the PFsense OpenVPN server side. As you will see below, it seems I can reach the other side of the tunnel, just not the LAN on the remote side:
Hurlock-Switch#ping 172.30.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.30.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms Hurlock-Switch#ping 10.4.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.4.0.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Hurlock-Switch#ping 10.4.0.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.4.0.11, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Also I think the routing table looks OK, but here is a snap from the client side:
Routing tables Internet: Destination Gateway Flags Netif Expire default gi-0-3-0-24-sur03\. UGS cpsw0 10.3.0.0/16 172.30.1.1 UGS ovpnc1 10.4.0.0/16 link#2 U cpsw1 abingdon-fw link#2 UHS lo0 126.96.36.199/30 link#1 U cpsw0 50-204-108-194-sta link#1 UHS lo0 188.8.131.52 gi-0-3-0-24-sur03\. UGHS cpsw0 localhost link#3 UH lo0 172.30.1.0/24 172.30.1.1 UGS ovpnc1 172.30.1.1 link#7 UH ovpnc1 172.30.1.2 link#7 UHS lo0
This one really has me going for sure..
Anyone have any ideas??