[SOLVED] Another lame OpenVPN client <-> LAN no access thread
-
Hello,
I'm setting up a VPN network between a pfSense and some Windows OpenVPN clients.
The VPN client connects, pings the LAN IP but can't access LAN devices.
LAN devices can ping the virtual IP of the OpenVPN client though.
I have searched like every option that came into my mind, I cannot solve this.Could someone have a look and tell me if I am becomming stupid ?
Network schematics
[Windows computer]---------[pfSense1, bridged WAN]----(internet)----[pfSense2, bridged WAN]----------[LAN2 COMPUTERS] with: Windows computer IP: 10.210.100.55 Windows computer virtual tun IP: 10.13.37.1 pfSense1 LAN IP: 10.210.100.254 pfSense1 LAN Subnet: 10.210.100.0/24 pfSense2 LAN2 IP: 172.16.1.1 pfSense2 LAN2 Subnet: 172.16.0.0/24 LAN2 computers have pfSense2 as their gatewaypfSense1 just happens to be there and is not involved with the VPN link.
on pfSense2: /var/etc/openvpn/server1.conf content:
dev ovpns1 verb 1 dev-type tun tun-ipv6 dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC auth SHA1 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 192.168.1.253 tls-server server 10.13.37.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc/server1 client-cert-not-required username-as-common-name auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' false server1" via-env tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'remote.somelan.local' 1" lport 48885 management /var/etc/openvpn/server1.sock unix max-clients 2 push "route 172.16.0.0 255.255.0.0" push "dhcp-option DOMAIN somelan.local" push "dhcp-option DNS 172.16.1.1" push "register-dns" push "dhcp-option NTP 172.16.1.1" push "redirect-gateway def1" ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.2048 tls-auth /var/etc/openvpn/server1.tls-auth 0 comp-lzo adaptive persist-remote-ip float topology subnetWindows OpenVPN client config file:
dev tun persist-tun persist-key cipher AES-256-CBC auth SHA1 tls-client client resolv-retry infinite remote pfsense2.wan.ip 48885 udp lport 0 auth-user-pass ca etablissement-wifi-udp-48885-ca.crt tls-auth etablissement-wifi-udp-48885-tls.key 1 ns-cert-type server comp-lzo adaptiveWindows routing table once connected (using route print)
IPv4 Table de routage =========================================================================== Itinéraires actifs : Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique 0.0.0.0 0.0.0.0 10.210.100.254 10.210.100.55 10 0.0.0.0 128.0.0.0 10.13.37.1 10.13.37.2 20 10.13.37.0 255.255.255.0 On-link 10.13.37.2 276 10.13.37.2 255.255.255.255 On-link 10.13.37.2 276 10.13.37.255 255.255.255.255 On-link 10.13.37.2 276 10.210.100.0 255.255.255.0 On-link 10.210.100.55 266 10.210.100.55 255.255.255.255 On-link 10.210.100.55 266 10.210.100.255 255.255.255.255 On-link 10.210.100.55 266 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 128.0.0.0 128.0.0.0 10.13.37.1 10.13.37.2 20 172.16.0.0 255.255.0.0 10.13.37.1 10.13.37.2 20 [pfSense2WANIP] 255.255.255.255 10.210.100.254 10.210.100.55 10 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 10.210.100.55 266 224.0.0.0 240.0.0.0 On-link 10.13.37.2 276 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 10.210.100.55 266 255.255.255.255 255.255.255.255 On-link 10.13.37.2 276Of course, I do launch OpenVPN gui with admin privileges.
OpenVPN interface firewall rule
IPv4 * * * * * noneLAN interface firewall rule (where LB1 is a gateway group of which WAN1 is primary tier.)
IPv4 LAN net * * * LB1 qACK/qOthersHighAnd yes, I already tried changing LB1 to WAN1.
I created the OpenVPN configs manually without the wizard. Anything I forgot like a static route back to the 10.13.37.0/24 network or an outgoing NAT rule ?Any errors please ?
-
And what about the firewall running on the clients your trying to access? Out of the box windows for example blocks access from devices that are not on its same local network. Your vpn clients would not be on the same local network as your boxes..
This is like 1st thing to look into when you can not access stuff..
-
Yep, I had AV / windows firewall disabled for my tests, didn't mention it because I kinda lost my mind on this today.
I've noticed some VERY strange behavior when using tracert under windows (sorry for the french console output):
C:\Windows\system32>tracert 172.16.1.1 Détermination de l'itinéraire vers somelan.local [172.16.1.1] avec un maximum de 30 sauts : 1 74 ms 76 ms 70 ms somelan.local [172.16.1.1] Itinéraire déterminé. C:\Windows\system32>tracert 172.16.1.9 Détermination de l'itinéraire vers 172.16.1.9 avec un maximum de 30 sauts. 1 83 ms 89 ms 70 ms 192.168.1.1 2 125 ms * 142 ms reverse-dns-of-my-pfsense2-wan [XX.XX.XX.XX] 3 * * * Délai d'attente de la demande dépassé. 4 * * * Délai d'attente de la demande dépassé. 5 * * ^C C:\Windows\system32>I don't have any 192.168.1.0/24 net anywhere.
Double checked with ipconfig and route print on the windows machine.
Routing magic ? -
1 83 ms 89 ms 70 ms 192.168.1.1
Clearly you do! ;)
-
That looks suspiciously like a WAN gateway IP you'd get when your behind another DSL router.
Are you sure your DSL is actually "bridged"?
What's the first two octets of your WAN IP? -
Why would you ever see pfsense wan IP in this trace either.. That would never show up with rfc1918 address as hop before that.. And if had a tunnel going, for sure never ever see your wan IP in the trace.
-
Indeed, yesterday I've tried to connect to another of my pfSense boxes that is behind a router with 192.168.1.0/24 network and forgot to switch back.
So far so good, tracert seems better when connecting to the pfSense I described above (which is bridged to a WAN modem).
C:\Windows\system32>tracert 172.16.1.1 Détermination de l'itinéraire vers partdieu-wifi.dghotels.local [172.16.1.1] avec un maximum de 30 sauts : 1 85 ms 71 ms 66 ms partdieu-wifi.dghotels.local [172.16.1.1] Itinéraire déterminé. C:\Windows\system32>tracert 172.16.1.3 Détermination de l'itinéraire vers 172.16.1.3 avec un maximum de 30 sauts. 1 47 ms 48 ms 48 ms 10.13.37.1 2 * * * Délai d'attente de la demande dépassé. 3 * * * Délai d'attente de la demande dépassé. 4 * * * Délai d'attente de la demande dépassé. 5 * * * Délai d'attente de la demande dépassé. 6 * * * Délai d'attente de la demande dépassé. 7 * ^CRouting table still seems to have the right 172.16.0.0/16 network
IPv4 Table de routage =========================================================================== Itinéraires actifs : Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique 0.0.0.0 0.0.0.0 10.210.100.254 10.210.100.47 10 0.0.0.0 128.0.0.0 10.13.37.1 10.13.37.2 20 10.13.37.0 255.255.255.0 On-link 10.13.37.2 276 10.13.37.2 255.255.255.255 On-link 10.13.37.2 276 10.13.37.255 255.255.255.255 On-link 10.13.37.2 276 10.210.100.0 255.255.255.0 On-link 10.210.100.47 266 10.210.100.47 255.255.255.255 On-link 10.210.100.47 266 10.210.100.255 255.255.255.255 On-link 10.210.100.47 266 [public ip pfSense2] 255.255.255.255 10.210.100.254 10.210.100.47 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 128.0.0.0 128.0.0.0 10.13.37.1 10.13.37.2 20 172.16.0.0 255.255.0.0 10.13.37.1 10.13.37.2 20 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 10.210.100.47 266 224.0.0.0 240.0.0.0 On-link 10.13.37.2 276 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 10.210.100.47 266 255.255.255.255 255.255.255.255 On-link 10.13.37.2 276 ===========================================================================I've enabled "Log packets that are handled by this rule" on the OpenVPN interface in pfSense, and the packets seem to reach the LAN.
(Pass) Jun 22 14:25:00 ovpns1 10.13.37.2 172.16.1.3 ICMPSo it seems that my windows client can reach the LAN, but doesn't get a reponse.
-
yeah you need to check the lan box your trying to ping and see where its sending the response if it is, is it possible your windows machine has a different gateway then the pfsense box your vpn tunnel is coming in on.
Easy enough to sniff on the lan box to see if its actually seeing the ping and what it does about it.
-
Okay, well… sometimes a good sleeping night should be considered before posting.
Most of the devices I need to remotely access aren't computers but switches and WAPs.
Some of the switches (which I had the luck to pick) don't have gateways setup.
And on top of this, the remote computer I was playing with has been shutdown while I was using it as "working reference" !!! (going crazy).
So actually everything worked perfectly with my initial setup, just no luck with the devices I was pinging.In the end, as my setup is supposed to be more a tech VPN to remotely access network equipment, I ended up trading the tun for a tap setup, so I get a nice bridge and can access devices that don't have gateways setup.
Thanks for the help.
-
The proper solution is to use outbound NAT (on the interface where the said devices are connected to) to access devices that don't have a gateway option.
-
Is there an advantage of using a outgoing NAT vs TAP bridge ?
-
why sort of crap device does not have option for a gateway?? They must be the cheapest of the cheapest devices designed for home use only.. Any device work 2 cents that has the option for ip management would have option for gateway..
-
Well, in my use case (not road warrior but remote access to switches etc), it's just brilliant to get broadcast etc.
-
huh?? Accessing switches and broadcast have to do with each other how??
-
Being in the same local lan is a lot easier for my tasks, which don't require any road warrior worker setup 8)
