OpenVPN "roadwarrior" connects, access to internet and pfSense, but not lan.

[gessel]

I think the key issue is that the LAN subnet is /8 (10.0.0.0/8).
The VPN is giving 192.168.10.0/24 addresses (and seems to do so correctly).
I've tried push "route 10.0.0.0 255.0.0.0" (and without).

OpenVPN has an allow IPv4* * * * * * rule (no other)
RA_VPN interface (the VPN) tried with/without an allow all rule.

I tried and deleted an interface mapping outbound NAT rule, but no difference either way.

when connected, the client (windows/android tested so far) can reach internet resources, DNS works, etc. They can also reach the pfSense GUI (at 10.101.50.152) but not LAN assets, for example 10.22.52.218.

Addresses seem correctly assigned (e.g. 192.168.10.2/24)

Much searching has not yet provided the key. Seemed like push route... was the key, but didn't seem to do anything. I note that one user with a very similar problem (https://www.reddit.com/r/PFSENSE/comments/7of2po/remote_access_openvpn_with_access_to_lan_subnet/) got "Tunnel Addresses:
10.0.3.2/24 -> 10.0.3.1"
In their client export after adding the push route, but I do not see that. mine looks like:

persist-tun
persist-key
cipher AES-256-CBC
ncp-ciphers AES-256-GCM:AES-256-CBC
auth SHA512
tls-client
client
resolv-retry infinite
remote {fqdn} 443 udp
setenv opt block-outside-dns
lport 0
verify-x509-name "remote_access_cert" name
remote-cert-tls server

which looks right, but no push routes sent to the client (not sure there should be, I'd think that'd be on the server)...

any hints?

-david

[chpalmer]

Mine is similar to yours with obvious differences.. Im actually connecting through this right now to see our driveway cam to watch the heavy snow from a much warmer location..

dev tun
persist-tun
persist-key
cipher AES-256-CBC
ncp-ciphers AES-128-GCM
auth SHA256
tls-client
client
resolv-retry infinite
remote {******} 1198 udp
auth-user-pass
ca *******-UDP4-1198-ca.crt
tls-auth ******-UDP4-1198-tls.key 1
remote-cert-tls server
redirect-gateway def1

[gessel]

I know this is a common problem, but it seems the causes and cures vary a bit. I've tried all the applicable ones i can, but still not able to reach LAN resources.

Some additional data for the experts here who might be able to help:

Connection works fine, routing to the internet works fine, but routing to the LAN doesn't seem to work, at least from the LAN to the connected clients Though, strangely, I can ping the android client from a windows 10 lan device, but not the windows client, but pinging from the android client to the same windows machine fails.

Like most of the people trying to sort this out, the pfsense GUI is available.

pfSense supplies DHCP, NTP, etc.

LAN: 10.0.0.0/8
IPv4 tunnel settings 192.168.10.0/24

Custom options:
push "redirect-gateway def1";
push "route 10.0.0.0 255.0.0.0";
push "dhcp-option DNS 10.101.50.152";

(I'd think the push dhcp-option DNS is redundant given the Advanced Client Settings)

• I can ping both my android and windows OpenVPN clients from pfSense
• I can ping my android client but not my windows client from a windows 10 machine on the LAN
• I can ping pfSense from both the android client and windows 10 client.
• I can't ping any LAN asset (other than pfSense) from either the windows client nor the android client (nor load any pages, i.e. not just ICMP)).

Some packet captures to illustrate:

• packet capture on OVPN interface of pfsense from pfsense (10.101.50.152) to android client (192.168.10.3)

14:00:00.977140 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 15096, offset 0, flags [none], proto ICMP (1), length 84)
192.168.10.1 > 192.168.10.3: ICMP echo request, id 47952, seq 0, length 64
14:00:01.182689 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 40113, offset 0, flags [none], proto ICMP (1), length 84)
192.168.10.3 > 192.168.10.1: ICMP echo reply, id 47952, seq 0, length 64

• packet capture on OVPN interface of pfsense from pfsense (10.101.50.152) to windows client(192.168.10.4)

14:00:53.091072 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 39029, offset 0, flags [none], proto ICMP (1), length 84)
192.168.10.1 > 192.168.10.4: ICMP echo request, id 35963, seq 0, length 64
14:00:53.170480 AF IPv4 (2), length 88: (tos 0x0, ttl 128, id 21274, offset 0, flags [none], proto ICMP (1), length 84)
192.168.10.4 > 192.168.10.1: ICMP echo reply, id 35963, seq 0, length 64

• packet capture on OVPN interface of pfsense from windows LAN device (10.101.40.2) to windows client(192.168.10.4)

14:02:49.598382 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 7069, offset 0, flags [none], proto ICMP (1), length 60)
10.101.40.2 > 192.168.10.4: ICMP echo request, id 1, seq 187, length 40
14:02:54.425695 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 7070, offset 0, flags [none], proto ICMP (1), length 60)
10.101.40.2 > 192.168.10.4: ICMP echo request, id 1, seq 188, length 40

(no reply)

• packet capture on OVPN interface of pfsense from windows LAN device (10.101.40.2) to android client(192.168.10.3)

14:03:53.351483 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 17394, offset 0, flags [none], proto ICMP (1), length 60)
10.101.40.2 > 192.168.10.3: ICMP echo request, id 1, seq 190, length 40
14:03:53.862459 AF IPv4 (2), length 64: (tos 0x0, ttl 64, id 30391, offset 0, flags [none], proto ICMP (1), length 60)
192.168.10.3 > 10.101.40.2: ICMP echo reply, id 1, seq 190, length 40

• packet capture on OVPN interface of pfsense from android client(192.168.10.3) to pfsense (10.101.50.152)

14:06:39.342683 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 12079, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.10.3 > 10.101.50.152: ICMP echo request, id 1105, seq 1, length 64
14:06:39.342732 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
10.101.50.152 > 192.168.10.3: ICMP echo reply, id 1105, seq 1, length 64

• packet capture on OVPN interface of pfsense from windows client (192.168.10.4) to pfsense (10.101.50.152)

14:08:23.902508 AF IPv4 (2), length 64: (tos 0x0, ttl 128, id 6218, offset 0, flags [none], proto ICMP (1), length 60)
192.168.10.4 > 10.101.50.152: ICMP echo request, id 1, seq 205, length 40
14:08:23.902552 AF IPv4 (2), length 64: (tos 0x0, ttl 64, id 14676, offset 0, flags [none], proto ICMP (1), length 60)
10.101.50.152 > 192.168.10.4: ICMP echo reply, id 1, seq 205, length 40

• packet capture on OVPN interface of pfsense from windows client (192.168.10.4) to windows LAN device (10.101.40.2)

14:09:29.182463 AF IPv4 (2), length 64: (tos 0x0, ttl 128, id 13016, offset 0, flags [none], proto ICMP (1), length 60)
192.168.10.4 > 10.101.40.2: ICMP echo request, id 1, seq 209, length 40
14:09:34.070600 AF IPv4 (2), length 64: (tos 0x0, ttl 128, id 13017, offset 0, flags [none], proto ICMP (1), length 60)
192.168.10.4 > 10.101.40.2: ICMP echo request, id 1, seq 210, length 40

(no reply)

• packet capture on OVPN interface of pfsense from android client (192.168.10.3) to windows LAN device (10.101.40.2)

14:11:39.782586 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 50500, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.10.3 > 10.101.40.2: ICMP echo request, id 1112, seq 1, length 64
14:11:43.822557 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 50686, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.10.3 > 10.101.40.2: ICMP echo request, id 1113, seq 1, length 64

(no reply)

Firewall Rules:
Floating: None
WAN:

LAN:

OPT1 (integrated wifi):

OpenVPN

[gessel]

Also, just for completeness, I tried creating an interface (and not, and then again) - to no avail. It looks like this:

and then added the following rule:

Pretty traffic logs, but still not connecting LAN to oVPN devices...

[gessel]

On closer inspection, it appears that the problem is certain assets dropping any request coming from outside their assigned address range.

This appears to be a crude and problematic security "feature" and has been brought up with the manufacturer. If I can verify, I'll mark this is solved.

it may be necessary to configure as peer-peer and put each connecting client in the address range of the LAN, which, given we're using a class A as a classification system, there's plenty of class C ranges not internally assigned.

Will update with any progress.