pfSense refuses to route from LAN to openVPN
birnbacs last edited by
This is a second posting after I could not get feedback on the one I posted in the openVPN section. The problem does not appear to be related to openVPN, after all; maybe one of you guys has an idea.
So, I have a couple of pfSense routers and established a site-to-site openVPN network between them. A is the openVPN server, B is the openVPN client. The connection works fine, only B refuses to route to or from LAN (or OPT1 or OPT2).
openVPN runs network 192.168.100.0/24 and assigns 192.168.100.1 to the server (A) and 192.168.100.2 to the client (B).
Routes seem OK and are used for pinging from B to A, but not for pinging the same address from a host attached to B (I checked the use counter).
[2.4.4-RELEASE][email@example.com]/root: netstat -rWn Routing tables Internet: Destination Gateway Flags Use Mtu Netif Expire default 192.168.178.1 UGS 42820 1500 igb0 127.0.0.1 link#6 UH 464 16384 lo0 192.168.100.0/24 192.168.100.1 UGS 0 1500 ovpnc1 192.168.100.1 link#9 UH 10152 1500 ovpnc1 192.168.100.2 link#9 UHS 0 16384 lo0 192.168.178.0/24 link#1 U 43705 1500 igb0 192.168.178.2 link#1 UHS 0 16384 lo0 192.168.220.0/24 192.168.100.1 UGS 497 1500 ovpnc1 192.168.230.0/24 192.168.100.1 UGS 0 1500 ovpnc1 192.168.245.0/24 link#2 U 1474987 1500 igb1 192.168.245.1 link#2 UHS 0 16384 lo0 192.168.250.0/24 link#3 U 37930 1500 igb2 192.168.250.1 link#3 UHS 0 16384 lo0 Internet6: Destination Gateway Flags Use Mtu Netif Expire ::1 link#6 UH 9 16384 lo0 fe80::%igb0/64 link#1 U 0 1500 igb0 fe80::2e0:67ff:fe16:e989%igb0 link#1 UHS 0 16384 lo0 fe80::%igb1/64 link#2 U 197 1500 igb1 fe80::1:1%igb1 link#2 UHS 0 16384 lo0 fe80::%igb2/64 link#3 U 0 1500 igb2 fe80::2e0:67ff:fe16:e98b%igb2 link#3 UHS 0 16384 lo0 fe80::%lo0/64 link#6 U 0 16384 lo0 fe80::1%lo0 link#6 UHS 0 16384 lo0 fe80::2e0:67ff:fe16:e989%ovpnc1 link#9 UHS 0 16384 lo0
FW on both pfSense machines are wide, wide open and every packet is logged.
I made sure there is no IPsec service active on B. However, there is one running on A; I use it to manage A from remote. However, there once was one set up on B. Any chance there is some residual setting even after disabling it and cleaning up? This is the only thing that would make sense to me as ipsec bypasses the routing table.
One more thing: I tried pinging from B through different interfaces (Diagnostics->Ping) like the handbook suggests. It appears that IPv4 is blocked from WAN and LAN IPv4 interfaces, but through corresponding IPv6 interfaces traffic reaches the target. This is a bit wondersome to me as all interfaces on both machines are configured for v4 only and the openVPN server serves IPv4 only.
Comments or ideas, gentlemen?
birnbacs last edited by
I got my issue resolved and feel quite relieved - but also kind of embarassed for taking so long to find the problem. In the hope that it might save someone else from digging around for days, here is what I found.
Problem was: private IPs will not be routed. All my 192.168.xx.yy/24 networks are private networks and I force-routed them a little way but could not get them through all the way.
Solution was: set an outgoing NAT rule:
Again: router A is the openVPN server, it has subnet 192.168.225.0/24. The above setting is for router B, which has subnet 192.168.245.0/24 for LAN. This permits a host in B's subnet to reach a host in A's subnet. A corresponding NAT rule will be required on A for the opposite direction.
I my case server A will assign an interface address to B, so the NAT address needs to be B's openVPN interface address.
What else did I learn?
For one thing, Apple's version of
pingsupports some really helpful options:
- -A will make a sound for each outgoing packet
- -a will make a sound for each incoming response
- -f will flood the target with ICMP packets. On an otherwise quiet system, this permitted me to see where my packets were going just by looking at pfSense's traffic graphs on the dashboard.
Another thing is, it took me ages to get to the solution but I feel that all the failures I have been through taught me more than I ever wanted to know Keep working on your problems, eventually you will master them!