[SOLVED] Another lame OpenVPN client <-> LAN no access thread
-
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)
