OpenVPN Communication Problem
I recently completely redid my netgate XG-7100. I am trying to set up my OpenVPN connection again and have tried multiple times with no luck. I haven't had any issues before, so I'm not sure what I might be overlooking. I can connect my client to the VPN with no problems, but I am not able to even ping the OpenVPN gateway or any connections on the LAN. I force all data through the tunnel, so I'm not able to access the internet either.
On a packet capture, I see data on the OpenVPN interface coming from the client (ping, network connection attempts, etc), but there are no responses. I checked that there is a default allow any to any rule in the OpenVPN firewall section. There is also a generated rule to allow the incoming OpenVPN connection (I can get a successful VPN client to server connection).
Any help would be great! I'm hoping it is something simple I'm overlooking. Let me know if any other info is needed to help. Thanks!
Here is my server config:
keepalive 10 60
server 10.10.6.0 255.255.255.0
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user TG9jYWwgRGF0YWJhc2U= false server1 1194
tls-verify "/usr/local/sbin/ovpn_auth_verify tls '#####.com' 1"
management /var/etc/openvpn/server1.sock unix
push "dhcp-option DOMAIN #####.com"
push "dhcp-option DNS 10.10.5.101"
push "dhcp-option NTP 10.10.5.1"
push "redirect-gateway def1"
push "redirect-gateway ipv6"
tls-auth /var/etc/openvpn/server1.tls-auth 0
push "route 10.10.5.0 255.255.255.0"
Here is my client config (certificates removed):
remote #####.com 1194 udp
setenv opt block-outside-dns
verify-x509-name "#####.com" name
Here is a packet capture of the OpenVPN interface:
19:22:17.985160 IP 10.10.6.2.63481 > 10.10.5.101.53: UDP, length 34
19:22:18.991818 IP 10.10.6.2.63481 > 10.10.5.101.53: UDP, length 34
19:22:19.990964 IP 10.10.6.2.63481 > 10.10.5.101.53: UDP, length 34
19:22:20.844572 IP 10.10.6.2.64336 > 10.10.5.101.53: UDP, length 39
19:22:21.830416 IP 10.10.6.2.64336 > 10.10.5.101.53: UDP, length 39
19:22:21.993781 IP 10.10.6.2.63481 > 10.10.5.101.53: UDP, length 34
19:22:23.836645 IP 10.10.6.2.64336 > 10.10.5.101.53: UDP, length 39
19:22:26.009104 IP 10.10.6.2.63481 > 10.10.5.101.53: UDP, length 34
19:22:26.258162 IP 10.10.6.2 > 10.10.6.1: ICMP echo request, id 1, seq 10, length 40
19:22:30.033676 IP 10.10.6.2.63711 > 10.10.5.101.53: tcp 0
19:22:30.138421 IP 10.10.6.2.55898 > 10.10.5.101.53: UDP, length 39
19:22:31.022223 IP 10.10.6.2.63711 > 10.10.5.101.53: tcp 0
19:22:31.106234 IP 10.10.6.2 > 10.10.6.1: ICMP echo request, id 1, seq 11, length 40
19:22:31.137605 IP 10.10.6.2.55898 > 10.10.5.101.53: UDP, length 39
19:22:33.034128 IP 10.10.6.2.63711 > 10.10.5.101.53: tcp 0
19:22:33.145233 IP 10.10.6.2.55898 > 10.10.5.101.53: UDP, length 39
19:22:36.134671 IP 10.10.6.2 > 10.10.6.1: ICMP echo request, id 1, seq 12, length 40
19:22:37.038483 IP 10.10.6.2.63711 > 10.10.5.101.53: tcp 0
@sgnoc Try to remove the firewall rule in openvpn tab, that is for the server.
@mcury I'm not sure I have the same setup. I'm not understanding why I need to create an interface for the OpenVPN server to pass data into the network. I didn't have to do that previously. My pfsense is running the OpenVPN server and not a client,. Was your situation running pfsense as the client connecting to an OpenVPN server remotely?
I tried it anyway, but didn't get anywhere with it. I disabled all rules in the OpenVPN Server firewall settings and created an OpenVPN interface with an allow any any rule, but still had the same result.
I ran PCAPs again to see what the traffic looks like with the interface created. It doesn't seem to be a return issue, it is not allowing traffic out. The OpenVPN Server interface (default created) is showing ping echo requests, the newly created OpenVPN interface shows the same ping echo requests, and my LAN does not show anything from the VPN subnet. I did also see some residual ssl traffic on port 443 that got forwarded into the OpenVPN Server interface (like it should with all traffic forced into the interface from the remote client).
I had this setup before with just the OpenVPN default generated interface for the server with no problems. I have even don't pass any any rules on the LAN and OpenVPN server, but the traffic is still being stopped at the VPN interface.
I've been pulling hair out for days on this, when I haven't ever had an issue getting it setup in pfsense before. What is the difference between using the OpenVPN Server's generated interface for firewall definitions and creating a new interface in the assignments tab to use for firewall rules?
@sgnoc "I'm not sure I have the same setup. I'm not understanding why I need to create an interface for the OpenVPN server to pass data into the network. I didn't have to do that previously. My pfsense is running the OpenVPN server and not a client,. Was your situation running pfsense as the client connecting to an OpenVPN server remotely?"
Yes, in my situation I was running my pfsense as an openvpn client..
So that firewall rule in openvpn tab was not allowing the reply-to to work..
When I removed that rule from the openvpn tab in my pfsense (client side), the reply packets started to work instantly.
I left only the firewall rules for the created openvpn interface at that time..
@mcury Ok, thanks. That makes sense. With my server running on pfSense, it almost seems like the server is not allowing packets in/out. I can see traffic from the remote client getting to the interface, but then nothing. I've never come across this issue before.
@sgnoc Trying to figure it out but nothing else is in my mind at this point.
Maybe someone will help you further.
In case something cross my mind, I'll update here.
@mcury Well, after the last several days going at this, I decided to do another reboot of my pfsense. I had a strange crash code once I restarted, so I rebooted again to see if it was just a one time thing.
After rebooting I tested the VPN and everything is now working. Looks like my hardware just didn't want to cooperate with me.
Thanks for the troubleshooting! I still have no idea why it was giving me problems.