OpenVPN to management LAN
-
Hi,
I have a problem to create a VPN tunel from my LANs to a Management LAN
pfSense setup:
WAN: 1.1.1.1LAN:
VLAN1 - LAN1 - 172.16.30.0/24
VLAN2 - LAN2 - 172.16.40.0/24
VLAN3 - Management LAN - 192.168.254.0/24I have firewall rules set up so that LAN1 and LAN2 cannot access Management LAN.
I'd like to create a VPN tunel to access the management lan.
I've created a OpenVPN (with the wizard) and I'm able to connect to it but it's not possible to ping anything on the Management LAN.
VPN network 192.168.253.0/24Here is the client setup:
dev tun
persist-tun
persist-key
cipher AES-128-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote 1.1.1.1 1194 udp
lport 0
verify-x509-name "PrzegubServerCert" name
auth-user-pass
pkcs12 pfsense-udp-1194-dale.p12
tls-auth pfsense-udp-1194-dale-tls.key 1
ns-cert-type serverThe route is properly pushed to the client:
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.30.1 172.16.30.158 10
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
172.16.30.0 255.255.255.0 On-link 172.16.30.158 266
172.16.30.158 255.255.255.255 On-link 172.16.30.158 266
172.16.30.255 255.255.255.255 On-link 172.16.30.158 266
192.168.253.1 255.255.255.255 192.168.253.5 192.168.253.6 30
192.168.253.4 255.255.255.252 On-link 192.168.253.6 286
192.168.253.6 255.255.255.255 On-link 192.168.253.6 286
192.168.253.7 255.255.255.255 On-link 192.168.253.6 286
192.168.254.0 255.255.255.0 192.168.253.5 192.168.253.6 30
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.253.6 286
224.0.0.0 240.0.0.0 On-link 172.16.30.158 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.253.6 286
255.255.255.255 255.255.255.255 On-link 172.16.30.158 266OpenVPN firewall rules are added by wizard.
Any idea what else I need to add to get this working?
-
OpenVPN firewall rules are added by wizard.
Great. What are they? That's probably where the problem is.
-
WAN:
IPv4 UDP * * WAN address 1194 (OpenVPN) * none OpenVPN wizardOpenVPN:
IPv4 * * * * * * none OpenVPN wizardNothing in NAT outbound.
I thought this was the problem but couldn't find any information on needed outbound rules.
I've tried to add some rules but it didn't work -
Pinging from OpenVPN to Management requires no more rules than that.
Are you sure the devices on management allow pings from other subnets?
Why are routes for LAN active at the same time? Are you trying to connect to OpenVPN from inside your network? I have no idea if that'll work. If so have you tried it from outside?
LAN:
VLAN1 - LAN1 - 172.16.30.0/24172.16.30.0 255.255.255.0 On-link 172.16.30.158 266
172.16.30.158 255.255.255.255 On-link 172.16.30.158 266 -
Yes, I think the OP has a client computer in LAN that has an OpenVPN client connecting to WAN port 1194, which then tries to access the Management network. In principle that should work. Maybe there is some problem with the way a "road warrior" OpenVPN can come out of LAN, NATed to public WAN IP and find itself connecting to port 1194 on the same WAN IP. This might be related to things that need NAT reflection.
If you just want to connect from inside LAN, then your OpenVPN server could be listening on LAN address - and the client connects directly to that. Maybe that will work. And actually you can port forward from WAN address 1194 to LAN address 1194 so that an outside connection will find its way also.Trying just a ping to the inside tunnel IP ends would be interesting, and a traceroute from client to mgt lan to see if there is any evidence that the packet/s are rying to traverse the tunnel.
-
Pinging from OpenVPN to Management requires no more rules than that.
Are you sure the devices on management allow pings from other subnets?
Why are routes for LAN active at the same time? Are you trying to connect to OpenVPN from inside your network? I have no idea if that'll work. If so have you tried it from outside?
It's possible and that's how it should be set up.
The management lan is a isolated lan for administration of the network and the only way to access it should be via VPN (from inside or outside that's why openVPN runs on WAN)
The rules on all other LANs are blocking all traffic to the management lan.Yes, I think the OP has a client computer in LAN that has an OpenVPN client connecting to WAN port 1194, which then tries to access the Management network. In principle that should work. Maybe there is some problem with the way a "road warrior" OpenVPN can come out of LAN, NATed to public WAN IP and find itself connecting to port 1194 on the same WAN IP. This might be related to things that need NAT reflection.
If you just want to connect from inside LAN, then your OpenVPN server could be listening on LAN address - and the client connects directly to that. Maybe that will work. And actually you can port forward from WAN address 1194 to LAN address 1194 so that an outside connection will find its way also.Trying just a ping to the inside tunnel IP ends would be interesting, and a traceroute from client to mgt lan to see if there is any evidence that the packet/s are rying to traverse the tunnel.
And thanks to your ideas I think I figured it out.
The management network doesn't have a dhcp server (just like it should be since mostly it's to access switches that have static IPs).
I think that the gateway on the switches isn't set correctly and when I ping something from a different subnet the switch doesn't know where to send the reply. (This is a gues but I think it might be it)I'll check it after Christmas but I think that a one to one NAT that will bind the VPN client IP address to an IP inside the management network might solve this.
Or I'll just check all the equiptment and set the gateway properly. -
You should be able to just add an Outbound NAT rule on LAN, source "the VPN tunnel network", destination LAN net, NAT to LAN address.
The traffic from your client device should have a source IP in VPN tunnel network, so will match that NAT rule, be translated to LAN address, go to the switch/es and the switches can answer.