Site-to-Site OpenVPN - client side sending traffic out WAN - not tunnel

Everingham.Curtis

Hello, and thanks in advance for any help.

Here are my configurations:

Server's configuration at /var/etc/openvpn/server1.conf

dev ovpns2
verb 1
dev-type tun
tun-ipv6
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 udp
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local <server's wan="" interface="" ip="">ifconfig 10.10.10.1 10.10.10.2
lport 50001
management /var/etc/openvpn/server2.sock unix
route 10.2.2.0 255.255.255.0
secret /var/etc/openvpn/server2.secret
comp-lzo adaptive

Client's configuration at /var/etc/openvpn/client1.conf

dev ovpnc1
verb 1
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
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local <client's wan="" interace="" ip="">lport 0
management /var/etc/openvpn/client1.sock unix
remote <server's wan="" interface="" ip="">50001
ifconfig 10.10.10.2 10.10.10.1
route 10.1.1.0 255.255.255.0 # Put this into a client-specific override while troubleshooting this issue. Didn't change anything
secret /var/etc/openvpn/client1.secret
comp-lzo adaptive
resolv-retry infinite

I have setup firewall rules on both sides under OpenVPN interface - allow all IPV4 traffic
I also setup a firewall rule on the server - Allow all IPV4 UDP traffic on port 50001 with destination of WAN address

All connections from the server-side LAN (10.1.1.0/24) to the client-side LAN (10.2.2.0/24) work just like they should.

The problem I'm running into is that all connections the other direction appear to not be getting sent through the OpenVPN tunnel. For example, if I just try to do a ping from the client-side pfsense firewall to the server-side pfsense firewall (LAN IP), I get the following:

:/ ping 10.1.1.1

76 bytes from host-<isp gateway="" ip="" address="">. <isp-domain>(<isp gateway="" ip="" address="">): Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 c57c 0 0000 40 01 90b8 <client-side external="" ip=""> 10.1.1.1

This makes it look like the client-side router is not properly sending traffic bound for the server-side LAN through the VPN tunnel. It's getting sent out the WAN interface, and the ISP is understandably blocking the traffic since it's a non-routable IP. What I haven't been able to figure out is how to remedy the situation.

EDIT:
After further digging, I've found that hosts inside of the client-side LAN are able to ping devices on the server side, except for the PFSense box. I checked out the routing table, and I see a route that looks like it could be the culprit. What I'm confused about is that there is an entry that should override this one. Here are the first three entries from the client-side router's table:

default host- <isp gateway="" ip="">UGS re0
10.1.1.0 10.10.10.1 UGS ovpnc1
10.1.1.1 host- <isp gateway="" ip="">UGHS re0

If I understand right, the 2nd rule should trigger for a connection bound to 10.1.1.1, before the third line is processed, but that is not the case as connections to 10.1.1.1 are getting directed to the ISP Gateway</isp></isp></client-side></isp></isp-domain></isp></server's></client's></server's>

Everingham.Curtis

Should have been more patient/persistent, and kept working on it before I posted here. Eventually sorted this out myself.

For anyone referencing this article later, here's what the issue was:

I messed around with DNS settings just after getting the VPN online, because I want all internal DNS resolution to go to the server-side PFsense box (it's acting as DNS resolver). I had put an entry in the general setup, specifying my server-side pfsense box as a DNS server, with my client-side ISP IP as the gateway. This was causing a static route to be entered into the table, and was the root of the issues.

I still have some things to figure out with DNS, but the original issue I was posting about is now resolved.