OpenVPN for road warriors (=remote client) - unable to access LAN clients
-
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.
-
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?
-
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_TroubleshootingAs 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.
-
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_TroubleshootingMy 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>
-
There must be some other internal routing issue then.
Can you post the output of the following shell commands?
ifconfig -a
netstat -rn
-
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 392netstat -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 tun0Internet6:
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 tun0xl1 (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>
-
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.
-
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... -
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.
-
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.
