Can't access LAN IP's on other interfaces via OpenVPN

jacotec

Hi,

I'm using pfSense as DHCP, DNS, NTP server and as an OpenVPN access server in my network. I've got 3 isolated VLAN's, each has an own interface in pfSense:

LAN: 10.0.0.0/12
PRIO: 10.32.0.0/16
GUEST: 10.50.0.0/16

The OpenVPN is listening on the LAN interface and I did allow the access to the networks "10.0.0.0/12,10.32.0.0/16" in the server config. All is working very well and once connected I can access all devices on the 10.0.0.1/12 subnet.

The issue is: I can't connect to any IP on the 10.32.0.0/16 subnet which is connected via the "PRIO" interface. pfSense should normally know where it should send out the packets for 10.32.x.x clients (the PRIO interface), there is no firewall rule prohibiting this (OpenVPN has a pass rule to all networks/interfaces) … so I'm really puzzled.

Any ideas where the problem can be?

Thanks!
Marco

jacotec

OK, I found it!

I needed to add a manual NAT outbound rule to allow traffic from the OVPN network range to the "PRIO" network. The automatic rules are only covering the "LAN" network.

marvosa

Using NAT works, but it only masks the issue… it doesn't really solve it. The main issue is routing. Not to mention, by using NAT you lose auditing capabilities.

It's a routed tunnel, so all you just need to push 10.32.0.0/16 to your clients via the "IPv4 Local network(s)" line in your config.

jacotec

@marvosa: Awesome hint, I'll try that ASAP. I thought the NAT firewall entry is needed as there are the same generated automatically by pfSense for the LAN network.

I thought by entering the networks in the "Tunnel settings" -> "IPv4 Local network(s)" section of the OVPN server config pfSense would push that automatically to the clients.

jacotec

Sorry, seems to be a misunderstanding. You mean this (attached)? That was there from day 1 … what I added was the firewall NAT rule (also attached).

pfsense_OVPN.jpg_thumb

pfsense_firewall.jpg_thumb

marvosa

Ok, so then you basically need to verify a few things:

Verify the route for 10.32.0.0/16 is being created on the client
Verify the client is launching OpenVPN as administrator
Verify the software firewall on the endpoint device is configured to respond to traffic sourced outside of it's local subnet…. e.g. on windows devices, this is disabled by default
Verify all devices are using PFsense as the default gateway
Verify there are no old static routes sending traffic somewhere you don't expect

Here's what I would do until basic IP connectivity is established:

Disable the software firewall on the endpoint device
add an any/any rule to both the LAN and OpenVPN tabs in the firewall section on PFsense

At this point, if we assume the rest of your openvpn config is configured correctly, you should be able to ping everything on the 10.32.0.0/16 subnet. If not, you're looking at a deep dive into the root cause which would involve a packet capture and posting your server1.conf.

dhoffman98

And verify that the client that is connecting is coming from another network that is NOT the same as one of your subnets. Their routing metric will probably be lower and default traffic to that subnet would actually end up going out to the lower metric gateway.

In other words…. If the IP of the client machine is 10.32.10.21 (for example), and then they connect to your VPN instance, I wouldn't be surprised to see traffic to another 10.32.0.0/16 gateway on their local network.

This is where setting up pfSense even becomes an issue if you happen to be on a network where 192.168.1.1 is already used. ;) (Found that one the hard way LOL)

jacotec

@marvosa:
After adding the NAT outbound rule in the firewall all is fine. I can access all machines on 10.32.0.0/16 without issues. Just SIP RTP to my PBX is not working, but I think that's more on the PBX side as I think it'll pass the outside IP in the SIP headers because it thinks 10.250.250.0/24 is an outside IP.

I'm negotiating this with the PBX mfr.

@dhoffman98:
I know these problems g … especially when traveling and the hotel WiFi is in the same 10.x IP range I use and I can't access my network from my notebook. Since a few months I've always got my GL-AR300M with me which decouples the IP range for my devices from that ;-)

Also a reason to choose 10.250.250.x as VPN IP range ... that does normally not collide with anything.