openVPN traffic routing refused on VPN client side

birnbacs

Dear all,

I have a strage routing problem that I have so far failed to tackle, and all help is appreciated.

I am running two pfSense 4-port routers of identical make, one (A) in the office, one (B) at home.
A and B both are each connected to a Fritz!Box, driving DSL to a local fiber modem to an ISP.
A has a dynamic IP (v4) and its Fritz does port forwarding. B only has DSlite.
They are interconnected with openVPN, A being the server and B the client.

A has subnets 192.168.225/24, 192.168.230/24 and 192.168.235/24 on assigned interfaces.
B has subnets 192.168.240/24 (currently unused), 192.168.245/24 and 192.168.250/24 on assigned interfaces.
OpenVPN is configured to interconnect all three subnets of A with all three subnets of B.
The VPN network is 192.168.100.0/24, with A getting 192.168.100.1, and B gettin 192.168.100.2.

The firewall is wide open for testing and all packets are logged.

What works:

A and B each provides internet access to the three local subnets and permits communication between subnets
B can access A and every host in any one of A’s subnets through openVPN
any host in one of A’s subnets can access B through openVPN

What does NOT work:

no host in a subnet of B can access A or a host connected thereto
neither A nor a host connected thereto can access a host in one of B’s subnets

In other words: B does not route openVPN traffic, neither out nor in. Again, the firewall is wide open and ipforwarding is enabled in the kernel.

I found that a connection attempt from an A-host to a B-host will be routed out through WAN rather than openVPN. If the "block local IP packets" option is removed from WAN, a traceroute clearly shows this.

The routes in B seem OK, though:

[2.4.4-RELEASE][admin@convect.here.us]/root: netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.178.1      UGS        igb0
127.0.0.1          link#6             UH          lo0
192.168.100.0/24   192.168.100.1      UGS      ovpnc1
192.168.100.1      link#9             UH       ovpnc1
192.168.100.2      link#9             UHS         lo0
192.168.178.0/24   link#1             U          igb0
192.168.178.2      link#1             UHS         lo0
192.168.220.0/24   192.168.100.1      UGS      ovpnc1
192.168.225.0/24   192.168.100.1      UGS      ovpnc1
192.168.230.0/24   192.168.100.1      UGS      ovpnc1
192.168.245.0/24   link#2             U          igb1
192.168.245.1      link#2             UHS         lo0
192.168.250.0/24   link#3             U          igb2
192.168.250.1      link#3             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
::1                               link#6                        UH          lo0
fe80::%igb0/64                    link#1                        U          igb0
fe80::2e0:67ff:fe16:e989%igb0     link#1                        UHS         lo0
fe80::%igb1/64                    link#2                        U          igb1
fe80::1:1%igb1                    link#2                        UHS         lo0
fe80::%igb2/64                    link#3                        U          igb2
fe80::2e0:67ff:fe16:e98b%igb2     link#3                        UHS         lo0
fe80::%lo0/64                     link#6                        U           lo0
fe80::1%lo0                       link#6                        UHS         lo0
fe80::%ovpnc1/64                  link#9                        U        ovpnc1
fe80::2e0:67ff:fe16:e989%ovpnc1   link#9                        UHS         lo0

Ideas, anyone?

chpalmer

@birnbacs Windows firewall will treat all out of subnet traffic as public.

Show your openvpn firewall rules..

birnbacs

pfSense's firewall rules are these:

I don't know about a Windows firewall. All client machines are Macs (which is essentially BSD), the servers run FreeBSD.

birnbacs

That's the B router (home). The A router has corresponding FW rules.

birnbacs

More ideas, anyone? Yes..?

birnbacs

Meanwhile I had a closer look at the extended routing table:

[2.4.4-RELEASE][admin@convect.here.us]/root: netstat -rWn4
Routing tables

Internet:
Destination        Gateway            Flags       Use    Mtu      Netif Expire
default            192.168.178.1      UGS       13179   1500       igb0
127.0.0.1          link#6             UH          451  16384        lo0
192.168.100.0/24   192.168.100.1      UGS           0   1500     ovpnc1
192.168.100.1      link#9             UH            6   1500     ovpnc1
192.168.100.2      link#9             UHS           0  16384        lo0
192.168.178.0/24   link#1             U         29247   1500       igb0
192.168.178.2      link#1             UHS           0  16384        lo0
192.168.220.0/24   192.168.100.1      UGS           0   1500     ovpnc1
192.168.225.0/24   192.168.100.1      UGS           0   1500     ovpnc1
192.168.230.0/24   192.168.100.1      UGS           0   1500     ovpnc1
192.168.245.0/24   link#2             U       1026844   1500       igb1
192.168.245.1      link#2             UHS           0  16384        lo0
192.168.250.0/24   link#3             U         37076   1500       igb2
192.168.250.1      link#3             UHS           0  16384        lo0

The "use" counter for the openVPN routes is increased during PINGs from B to A, but not when PINGing from a B-host to A.
No incoming packets are blocked by the FW as I can see from the logs.
NAT was turned off during this test, but even if it wasn't the outgoing traffic would have had to use the route.

I am wondering if the routes to the 220/225/230 networks should not show "link#9" as GW instead of 192.168.100.1. Well, how would I go about that?

Any help is greatly appreciated.

birnbacs

pfSense has a great little tool for PINGing through different interfaces (Diagnostics->Ping).
Here are the results for PINGing from the VPNclient B to a host connected to VPNserver A (192.168.22.21):

LAN v4: NO
LAN_v6_local: YES
OPT1 v4: NO
OPT1_v6_local: YES
WAN: NO
WAN_v6_local: YES
openvpn: YES
Automatic: NO
localhost: NO

So, IPv6 works, IP4 does not. Unfortunately that does not make me any wiser.
B is connected to a Fritz!Box that uses DS Lite, i.e. it tunnels IPv4 through IPv6. Does this mean I am restricted to using IPv6?

birnbacs

BTW: all interfaces on both A and B are configured to use IPv4 only.

birnbacs

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 will 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 the 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 ping supports 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!