OpenVPN for road warriors (=remote client) - unable to access LAN clients

[srizzi72]

Following tutorials I have configured pfSense OpenVPN.
From internet I'm able to open the OpenVPN connection to my pfSense box but I cannot access LAN clients. All staff as ping, tracert, telnet, vnc using IP address versus a server located in the LAN ends with timeout.
Only pfSense itself reply at the ping and I'm able to open the pfSense webgui via his "vpn ip" (192.168.98.1) and via his LAN IP (192.168.49.1).

The pfSense version is 1.2.3

OpenVPN Server settings are the following:

• Protocol: UPD
• Dynamic IP: checked
• Local Port: 1194
• Address pool: 192.168.98.0/24
• Use static IPs: not checked
• Local network: 192.168.49.0/24
• Remote network: left blank
• Client-to-client VPN: checked
• LZO compression: checked

Firewall Rules are:
WAN:
  Proto: UDP, Source: *, Port: *, Destination: *, Port: 1194, Gateway: *
LAN:
  Proto: *, Source: LAN net, Port: *, Destination: *, Port: *, Gateway: *
  Proto: *, Source: LAN net, Port: *, Destination: 192.168.98.0/24, Port: *, Gateway: *
  Proto: *, Source: 192.168.98.0/24, Port: *, Destination: LAN net, Port: *, Gateway: *

My LAN is 192.168.49.0/24, the pfSense is 192.168.49.1, other machines in the LAN are starting from 192.168.49.2, addresses provided by the DHCP server of pfSense.

Do you have some suggestions to help me?

[jimp]

It sounds like it isn't getting the proper route. Usually this is from one or two things:

1. Either "pull" or "client" missing from the client config. ("client" implies "pull" so both aren't needed)
2. When the client is Vista or Windows 7, it must be run as Administrator (right click icon and launch)

[srizzi72]

Thank you jimp, but…

my client is on WinXP (where my user is an administrator) and setting are:

float
port 1194
dev-node openvpn
ping 10
pkcs12 MyP12.p12
client
dev tun
proto udp
remote ... 1194
ping 10
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
comp-lzo
verb 3
route-method exe
mssfix 1200
route-delay 2

ipconfig output is:
Ethernet adapter openvpn:

Connection-specific DNS Suffix  . : *********.local
        Description . . . . . . . . . . . : TAP-Win32 Adapter V9
        Physical Address. . . . . . . . . : 00-FF-28-E0-35-00
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 192.168.98.6
        Subnet Mask . . . . . . . . . . . : 255.255.255.252
        Default Gateway . . . . . . . . . :
        DHCP Server . . . . . . . . . . . : 192.168.98.5
        DNS Servers . . . . . . . . . . . : 192.168.49.1
        Primary WINS Server . . . . . . . : 192.168.49.2
        NetBIOS over Tcpip. . . . . . . . : Disabled
        Lease Obtained. . . . . . . . . . : giovedì 29 aprile 2010 15.30.42
        Lease Expires . . . . . . . . . . : venerdì 29 aprile 2011 15.30.42

Default Gateway is blank, is correct?

[jimp]

What does the output of "route print" from a command prompt show? Does it include the route to your remote LAN?

[srizzi72]

Yes:

===========================================================================
Interface List
0x1 …........................ MS TCP Loopback interface
0x2 ...00 1c 23 5a 9b 0b ...... Broadcom NetXtreme 57xx Gigabit Controller - Pac
ket Scheduler Miniport
0x3 ...00 1f 3c 32 5b 4f ...... Intel(R) PRO/Wireless 3945ABG Network Connection

• Packet Scheduler Miniport
  0x4 ...00 ff 28 e0 35 00 ...... TAP-Win32 Adapter V9 - Packet Scheduler Miniport

0x10006 ...00 1e 37 c5 90 32 ...... Bluetooth Personal Area Network - Packet Sch
eduler Miniport

===========================================================================
Active Routes:
Network Destination        Netmask          Gateway      Interface  Metric
          0.0.0.0          0.0.0.0  134.128.85.254  134.128.84.13      20
          0.0.0.0          0.0.0.0  134.128.87.126  134.128.87.82      25
  83.222.226.133  255.255.255.255  134.128.87.126  134.128.87.82      1
    85.10.128.147  255.255.255.255  134.128.87.126  134.128.87.82      1
        127.0.0.0        255.0.0.0        127.0.0.1      127.0.0.1      1
    134.128.84.0    255.255.254.0    134.128.84.13  134.128.84.13      20
    134.128.84.13  255.255.255.255        127.0.0.1      127.0.0.1      20
    134.128.87.64  255.255.255.192    134.128.87.82  134.128.87.82      25
    134.128.87.82  255.255.255.255        127.0.0.1      127.0.0.1      25
  134.128.255.255  255.255.255.255    134.128.84.13  134.128.84.13      20
  134.128.255.255  255.255.255.255    134.128.87.82  134.128.87.82      25
    192.168.49.0    255.255.255.0    192.168.98.5    192.168.98.6      1
    192.168.98.0    255.255.255.0    192.168.98.5    192.168.98.6      1
    192.168.98.4  255.255.255.252    192.168.98.6    192.168.98.6      30
    192.168.98.6  255.255.255.255        127.0.0.1      127.0.0.1      30
  192.168.98.255  255.255.255.255    192.168.98.6    192.168.98.6      30
  213.140.22.226  255.255.255.255  134.128.87.126  134.128.87.82      1
        224.0.0.0        240.0.0.0    134.128.84.13  134.128.84.13      20
        224.0.0.0        240.0.0.0    134.128.87.82  134.128.87.82      25
        224.0.0.0        240.0.0.0    192.168.98.6    192.168.98.6      30
  255.255.255.255  255.255.255.255    134.128.84.13  134.128.84.13      1
  255.255.255.255  255.255.255.255    134.128.87.82  134.128.87.82      1
  255.255.255.255  255.255.255.255    192.168.98.6          10006      1
  255.255.255.255  255.255.255.255    192.168.98.6    192.168.98.6      1
Default Gateway:    134.128.85.254

Persistent Routes:
  None

Is it possible that pfSense is blocking packages from and to the OpenVpn tunnel?
There commands that i can run on pfSense to see routing/filtering or files that i can check in addition to settings shown from the pfSense WebGui?

[jimp]

pfSense doesn't filter OpenVPN traffic at all by default.

If it was, you would see entries in the firewall log showing the blocks.

[srizzi72]

In my first post i have reported all rules that are set on pfSense. All rules are with the "log" enabled.
When I try to access a machine in LAN network, no record are written in Status -> System logs -> Firewall matching involved IPs….
There is a way to monitor/see packages reaching my pfSense in order to understand where are going?? Seem they are lost inside pfSense box....

[jimp]

You can use Diagnostics > Packet Capture in the GUI, or tcpdump from the shell.

The LAN rules would only be triggered when connections were made from the LAN to elsewhere. They would not be triggered for incoming VPN traffic from OpenVPN.

[srizzi72]

Thak you jimp for your reply.

The LAN rules would only be triggered when connections were made from the LAN to elsewhere. They would not be triggered for incoming VPN traffic from OpenVPN.

Does this means that my two rules from/to LANnet/VPNnet are not needed?

As I'm suspecting that the problem is not only just related to OpenVPN I have created a NAT (Port Forwarding) to verify if packets are able to walk from Internet to machines on my LAN. Parameters are:

If      Proto  Ext.port range    NAT IP                                        Int. port range
WAN  TCP    80 (HTTP)        192.168.49.2 (ext.: 192.168.5.10)  80 (HTTP)

the result is a timeout… As shown in the System log->Firewall and in Packet Capture the package is received by the pfSense but is not sent to the LAN interface.
All rules are logging. The System log->Firewall report 1 row with:
Act=green IF=WAN Source=my internet ip Destination=192.168.49.2:80 Proto= TCP:S
No other rows form/to my internet ip and ip of the machine exposed with NAT (192.168.49.2).

With Packet Capture on WAN: one package from my internet ip to 192.168.5.10 port 80 and no other packages. (192.168.5.10 is the IP of WAN if)
With Packet Capture on LAN: no packages.

So, packages not generated on LAN (coming from WAN or from OpenVPN) are stopped. Note that LAN clients are able to navigate in internet...

What I can check to verify if exists something blocking packages that instead (rules that i mentioned before) should walk through pfSense?

[jimp]

Does this means that my two rules from/to LANnet/VPNnet are not needed?

Correct. The rules going "to" the VPN might be needed but (a) they are underneath the more general allow rule so the rule would be skipped, and (b) your allow all rule would allow that anyhow. First match wins with firewall rules and many others.

Your port forward and VPN comparison is apples-and-oranges. One likely has very little to do with the other.

Do you have "block private networks" unchecked on Interfaces > WAN? That may be part of the issue, otherwise, try these things:
http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

As for the VPN, the port forward test is not indicative of any potential issue. You'd have to do a packet capture on LAN to see if the traffic made it out, and a packet capture on tun0 to see if the traffic is even coming in from the client.

[srizzi72]

Thank you jimp

Correct. The rules going "to" the VPN might be needed but (a) they are underneath the more general allow rule so the rule would be skipped, and (b) your allow all rule would allow that anyhow. First match wins with firewall rules and many others.

Rules cleaned!

Do you have "block private networks" unchecked on Interfaces > WAN? That may be part of the issue, otherwise, try these things:
http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

My provider is Fastweb and is using NAT over his network, the Fasweb router has IP 192.168.5.1 and the WAN ip must be 192.168.5.10. So i have left unchecked the "block private networks". Correct?

I have checked NAT and rules and are ok as specified in the link that you have sent me.

As for the VPN, the port forward test is not indicative of any potential issue. You'd have to do a packet capture on LAN to see if the traffic made it out, and a packet capture on tun0 to see if the traffic is even coming in from the client.

using tcpdump on tun0 when i try to open an http connection to the WebServer on my LAN via OpenVPN (ip: 192.168.49.2) the only line that is shown related to this connection is:

15:43:57.239205 IP 192.168.98.6.4416 > 192.168.49.2.http: S 1323696919:1323696919(0) win 64512 <mss 1118,nop,nop,sackok="">all other lines are related to ssh connection i have opened to run tcpdump command.

using tcpdump on re0 (LAN) when i try to open an http connection to the WebServer on my LAN via OpenVPN (ip: 192.168.49.2) no lines are shown. all other lines are related to lan traffic vs internet.

using tcpdump on xl0 (WAN) when i try to open an http connection to the WebServer on my LAN via internet the only line that is shown related to this connection is:

15:48:02.673469 IP 134.128.87.72.4442 > 192.168.5.10.http: S 2497132998:2497132998(0) win 64512 <mss 1460,nop,nop,sackok="">all other lines are related to lan traffic vs internet and UDPs packet vs OpenVPN.

using tcpdump on re0 (LAN) when i try to open an http connection to the WebServer on my LAN via internet no lines are shown. all other lines are related to lan traffic vs internet.

Others things to check?</mss></mss>

[jimp]

There must be some other internal routing issue then.

Can you post the output of the following shell commands?

ifconfig -a

netstat -rn

[srizzi72]

ifconfig -a

xl0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
        options=8 <vlan_mtu>ether 00:10:4b:af:c7:63
        inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255
        inet6 fe80::210:4bff:feaf:c763%xl0 prefixlen 64 scopeid 0x1
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
xl1: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
        options=8 <vlan_mtu>ether 00:60:08:7b:f8:90
        media: Ethernet autoselect (none)
        status: no carrier
xl2: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
        options=8 <vlan_mtu>ether 00:60:08:7b:f1:67
        media: Ethernet autoselect (none)
        status: no carrier
re0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        options=3898 <vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_ucast,wol_mcast,wol_magic>ether 00:1a:92:34:89:8a
        inet 192.168.49.1 netmask 0xffffff00 broadcast 192.168.49.255
        inet6 fe80::21a:92ff:fe34:898a%re0 prefixlen 64 scopeid 0x4
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
enc0: flags=0<> metric 0 mtu 1536
pfsync0: flags=41 <up,running>metric 0 mtu 1460
        pfsync: syncdev: lo0 syncpeer: 224.0.0.240 maxupd: 128
pflog0: flags=100 <promisc>metric 0 mtu 33204
tun0: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
        inet6 fe80::210:4bff:feaf:c763%tun0 prefixlen 64 scopeid 0x9
        inet 192.168.98.1 –> 192.168.98.2 netmask 0xffffffff
        Opened by PID 392

netstat -rn

Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.5.1        UGS        0    11175    xl0
127.0.0.1          127.0.0.1          UH          0        0    lo0
192.168.5.0/24    link#1            UC          0        0    xl0
192.168.5.1        00:03:6f:e0:13:90  UHLW        2      170    xl0  1148
192.168.49.0/24    link#4            UC          0        0    re0
192.168.49.2      00:13:21:c9:18:89  UHLW        1    2926    re0  1064
192.168.49.36      00:23:ae:b0:b8:73  UHLW        1    3191    re0  1065
192.168.49.37      00:25:64:bc:f5:1d  UHLW        1    1906    re0    444
192.168.49.50      00:1d:92:3a:60:b1  UHLW        1      129    re0  1193
192.168.49.55      00:0b:82:15:46:df  UHLW        1        1    re0  1004
192.168.98.0/24    192.168.98.2      UGS        1    6008  tun0
192.168.98.2      192.168.98.1      UH          1        0  tun0

Internet6:
Destination                      Gateway                      Flags      Netif Expire
::1                              ::1                          UHL        lo0
fe80::%xl0/64                    link#1                        UC          xl0
fe80::210:4bff:feaf:c763%xl0      00:10:4b:af:c7:63            UHL        lo0
fe80::%re0/64                    link#4                        UC          re0
fe80::21a:92ff:fe34:898a%re0      00:1a:92:34:89:8a            UHL        lo0
fe80::%lo0/64                    fe80::1%lo0                  U          lo0
fe80::1%lo0                      link#5                        UHL        lo0
fe80::%tun0/64                    link#9                        UC        tun0
fe80::210:4bff:feaf:c763%tun0    link#9                        UHL        lo0
ff01:1::/32                      link#1                        UC          xl0
ff01:4::/32                      link#4                        UC          re0
ff01:5::/32                      ::1                          UC          lo0
ff01:9::/32                      link#9                        UC        tun0
ff02::%xl0/32                    link#1                        UC          xl0
ff02::%re0/32                    link#4                        UC          re0
ff02::%lo0/32                    ::1                          UC          lo0
ff02::%tun0/32                    link#9                        UC        tun0

xl1 (OPT1) and xl2 (OPT2) are not used/connected and are configured to use DHCP.</up,pointopoint,running,multicast></promisc></up,running></up,loopback,running,multicast></full-duplex></vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_ucast,wol_mcast,wol_magic></up,broadcast,running,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></full-duplex></vlan_mtu></up,broadcast,running,promisc,simplex,multicast>

[jimp]

That all looks correct. It's a bit of a mystery where that traffic is going then if it's not being blocked and also not coming out LAN.

It appears as though it should route properly based on what I see in the interface and route config you attached.

[srizzi72]

Hello jimp!
This weekend I have re-installed pfSense and then was working well, problem solved… until... until I have enabled Captive Portal! CAPTIVE PORTAL is the Mistery in my pfSense :-/
I can assure that enabling Captive Portal I'm no more able to access LAN clients... disabling Captive portal the LAN network is visible again...
Even if I set the ip of the LAN client that I want to access, when Captive Portal is enable that IP and the rest of the LAN network is no more visible. There is the option to "Disable MAC filtering" but doesn't solve the problem...

[jimp]

That could definitely be an issue there. I didn't know CP was involved at all.

You might need to make two internal LANs, one of clients protected by CP, and another for systems which need to be accessed from remote locations by VPN or port forwards.

[srizzi72]

oh… is not a best solution for me, btw, i will investigate a bit... and then will decide what to do.

Thank you so much for your help, your support and your time!
Stefano.