pfSense refuses to route from LAN to openVPN

[birnbacs]

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).

A:
LAN: 192.168.220.0/24
OPT1: 192.168.225.0/24
OPT2: 192.168.230.0/24

B:
LAN: 192.168.245.0/24
OPT1: 192.168.250.0/24
OPT2: 192.168.240.0/24

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][admin@convect.here.us]/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]

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 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!