[SOLVED] Another lame OpenVPN client <-> LAN no access thread

johnpoz

1 83 ms 89 ms 70 ms 192.168.1.1

Clearly you do! ;)

divsys

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?

johnpoz

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.

deajan

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     *     ^C

Routing 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	ICMP

So it seems that my windows client can reach the LAN, but doesn't get a reponse.

johnpoz

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.

deajan

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.

kpa

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.

deajan

Is there an advantage of using a outgoing NAT vs TAP bridge ?

johnpoz

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..

deajan

Well, in my use case (not road warrior but remote access to switches etc), it's just brilliant to get broadcast etc.

johnpoz

huh?? Accessing switches and broadcast have to do with each other how??

deajan

Being in the same local lan is a lot easier for my tasks, which don't require any road warrior worker setup 8)