OpenVPN client LAN access from server LAN

[marvosa]

@blackslash I see a few things:

• Unless the objective is to route all client-side traffic thru the server, you'll want to uncheck the "Redirect IPv4 Gateway" option.

• I would fill in the "IPv4 Local network(s)" section which will render the push route you have in the advanced section redundant and thus can be removed. This would be cleaner IMO.

• The server doesn't know where the client-side network is. You need to fill in the "IPv4 Remote network(s)" section so the route is created.

• On the OpenVPN tab, the source should be the client-side network (i.e. 192.168.10.0/24).

[blackslash]

@marvosa @viragomann

I have since had to switch to TAP due to domain broadcast requirement.

The config was updated to TAP and allow clients on bridge to obtain DHCP and bridge interface was set to LAN.

Clients connecting via the Teltonika which is configured as the OpenVPN client receives an IP via DHCP. From pfSense I can ping to any of these clients but clients cannot still communicate with one another.

Allow communication between clients connected to this server is ticked.

[blackslash]

Also to clarify, clients on the server LAN can communicate with one another and also client on Teltonika side once they receive an IP via DHCP can also communicate with one another. It's just that client communication over the VPN which is not working.

[blackslash]

Any ideas?

[blackslash]

@marvosa
For the sake of getting this to work, I switched back to TUN.

I will leave Redirect IPv4 Gateway ticked as I want all traffic from the client LAN to go via VPN.

I have filled in the Remote Network details as well. When I modify the OpenVPN firewall rule as you suggested, the client LAN devices can no longer ping the Server LAN devices or even vice versa.
Leaving the rule to any allows the client LAN devices to ping to server LAN but server LAN to Client LAN does not work. Any ideas?

[Gertjan]

@blackslash said in OpenVPN client LAN access from server LAN:

allows the client LAN devices to ping to server LAN but server LAN to Client LAN does not work. Any ideas?

Maybe, a question first.

This 'LAN server' and these "LAN clients" are all on the same LAN ?
Like the server uses 192.168.1.10 and the clients 192.168.1.15 and 192168.1.21 etc ?

If so, be advised : traffic from this server to a LAN client, or the LAN client to the server is never seen by pfSense ... traffic never enters the LAN interface ... so the pfSense LAN firewall rules not see this traffic. In theory, you could power down pfSense and nothing changes.

[blackslash]

@Gertjan

Thanks for getting back to me to. I have since updated the subnets since the original post was made.
No they are not, the LAN behind pfSense is on the 192.168.110.0/24 subnet. LAN behind the client which is a Teltonika RUT device has a bunch of sensors, which is on 192.168.15.0/24.

For testing purposes, I have connected a laptop onto the LAN of the Teltonika RUT devices and spun up a windows VM on the pfsense LAN.

From the laptop on the client end, I can ping pfSense and devices on the pfSense LAN (192.168.15.0/24 -> 192.168.110.0/24)

But from the VM or any device on the pfSense LAN, I cannot ping the devices which are on the client LAN (Teltonika LAN)

[marvosa]

@blackslash

When I modify the OpenVPN firewall rule as you suggested, the client LAN devices can no longer ping the Server LAN devices or even vice versa. Leaving the rule to any allows the client LAN devices to ping to server LAN but server LAN to Client LAN does not work. Any ideas?

If you moved to TUN, and presumably switched subnets on the client-side, the rules on the OpenVPN tab need to be adjusted accordingly. Also, need to determine if the client-side is NAT'ing traffic over the tunnel which would change your rule(s). Although, it's moot if you went to an any/any.

If you've switched to TUN, changed subnets, and added an any/any on the OpenVPN tab, we're probably looking at a firewall issue on the client-side.

Can you post:

• The routing table from both ends

• The firewall rule(s) from the OpenVPN tab on the server and wherever they live on the Teltonika side.

• The OpenVPN server config (/var/etc/openvpn/server1/config.ovpn)

I'm not familiar with Teltonika devices, but a few Google searches brought me here:

https://wiki.teltonika-networks.com/view/OpenVPN_Access_Control

and I'll bet this section needs to be adjusted on the Teltonika if it looks similar on your device:

[blackslash]

@marvosa Thank you kindly for responding.

I did stumble upon the Teltonika Wiki and had that change implemented but did not help.

Please see sanitized server config below

dev ovpns2
verb 5
dev-type tap
dev-node /dev/tap2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local xxx.xxx.xxx.xxx
tls-server
mode server
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'Name' 1"
lport 1194
management /var/etc/openvpn/server2/sock unix
push "redirect-gateway def1"
client-to-client
capath /var/etc/openvpn/server2/ca
cert /var/etc/openvpn/server2/cert 
key /var/etc/openvpn/server2/key 
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server2/tls-auth 0
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
data-ciphers-fallback AES-128-GCM
allow-compression no

Routable on pfsense

Routing table on Teltonika

Traffic rules on Teltonika

Zone rule on Teltonika

Firewall rule on pfSense

[marvosa]

@blackslash The config posted shows "dev-type tap". Did you move back to TAP, or is that an old config?

I also don't see a route statement to your client-side LAN in your config. Which would be why there's no route to 192.168.15.0/24 in PFsense's routing table. PFsense needs to know that the client-side LAN exists over the tunnel otherwise traffic sourced from the server-side won't get there.

The way that Teltonika interprets those zones is somewhat confusing, but basically, you need to allow the server-side LAN subnet access to the client-side LAN over the tunnel... and I'm not sure the current config is getting you there. It appears adjustments may need to be made to align with our config. Does the Teltonika have a syslog for the firewall? Once the server-side traffic is routed over there, you'll likely see blocks in the logs.

[blackslash]

@marvosa

I've been playing around with different configs to try and get this to work. At the moment on a TAP setup.

192.168.110.0/24 is the pfSense LAN which has been bridged to the Teltonika.

[marvosa]

@blackslash If you moved back to TAP, TAP extends layer 2, so you'd need to move the client-side over to 192.168.110.0/24, move the cliend-side to TAP, then bridge the tunnel interface to the LAN on both ends, which you may or may not have done already. However, the routing table on the client-side shows the LAN bridged to 192.168.15.0/24, so that'll need to be looked at.

Once the above is sorted out, I still think the client-side firewall needs some tweaking. You may want to add an any/any on the client-side as well until basic IP communication is established. Also, I don't believe you want to be NAT'ing over the the tunnel with your config.

You'll also want to define the DHCP scope on either end so there's no overlap, unless you have another solution in place to manage IP's.

[blackslash]

For anyone who stumbles upon this in the future, I know my config was correct, but I switched between OpenVPN (TAP & TUN), Wireguard and IPSec and they all had the same output. Communication issue between clients.

I then configured this on a test environment, and it all worked as it should which meant there was nothing wrong with the config.

I then pushed the people at the data center to investigate despite them saying there is nothing wrong on their end, and it ended up being a filter applied on the Public IP VLAN at the data center. Once they removed it, it just started to work as it should.

[Gertjan]

@blackslash

They were fire-walling port 1194 UDP traffic ?
They are anti OpenVPN ?