Weird LAN behaviour - LAN to internet
-
My setup is pretty much this
NAT out
WAN 127.0.0.0/8 * * * WAN address * Localhost to WAN WAN 10.0.0.0/24 * * * WAN address * LAN TO WAN WAN 10.0.10.0/24 * * * WAN address * VL10_MGMT to WAN WAN 10.0.20.0/24 * * * WAN address * VL20_VPN to WAN WAN 10.0.30.0/24 * * * WAN address * VL30_CLRNET to WAN WAN 10.0.40.0/24 * * * WAN address * VL40_GUEST to WAN VPN_WAN2 10.0.20.0/24 * * * VPN_WAN2 address * VL20_VPN to VPN_WAN VPN_WAN1 10.0.20.0/24 * * * VPN_WAN1 address * VL20_VPN to VPN1_WANAll sub nets on dhcp separate range and rules for sub nets and ports
LAN giving out 10.0.0.19 via Ethernet cable to LAN interface igb1
only noticed the problem when I turned off the wifi adapter on the notebook which had been connected to either vlan30(clear net) or vlan20(OPENVPN)States when pinging 9.9.9.9 from LAN ethernet
LAN icmp 10.0.0.19:15326 -> 9.9.9.9:15326 0:0 21 / 21 2 KiB / 2 KiB
WAN icmp 73.245.92.68:7006 (10.0.0.19:15326) -> 9.9.9.9:7006 0:0 21 / 21 2 KiB / 2 KiBpings are going out via isp not openvpn only 12ms
But no http or https via lan
LAN is connected to the correct MAC on the laptop in the table -
So before disconnecting the wifi the client had two connections to the same subnet?
That seems invalid.
Steve
-
It would seem so. Ping was going to the isp I guess as the return was quick -12ms from US - and http/s was via the VPN which at this time is Netherlands for leaktest.com - ping from European servers sem to be around 220ms
ifconfig gives
Link encap:Ethernet HWaddr f0:dxxxxxxx
inet addr:10.0.0.19 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::abe4:c19:4c94:98f4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:55304 errors:0 dropped:0 overruns:0 frame:0
TX packets:50052 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:24017385 (24.0 MB) TX bytes:6618596 (6.6 MB)
Interrupt:20 Memory:f2600000-f2620000lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:785515 errors:0 dropped:0 overruns:0 frame:0
TX packets:785515 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:107283334 (107.2 MB) TX bytes:107283334 (107.2 MB)wlan0 Link encap:Ethernet HWaddr 00:27:10:87:4xxxx
inet addr:10.0.20.17 Bcast:10.0.20.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 -
ifconfig gives two addresses at the same time eth0 10.0.0.19 and wlan0 10.0.20.17
Link encap:Ethernet HWaddr xxxxxxxxxxx
inet addr:10.0.0.19 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::abe4:c19:4c94:98f4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:55304 errors:0 dropped:0 overruns:0 frame:0
TX packets:50052 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:24017385 (24.0 MB) TX bytes:6618596 (6.6 MB)
Interrupt:20 Memory:f2600000-f2620000lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:785515 errors:0 dropped:0 overruns:0 frame:0
TX packets:785515 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:107283334 (107.2 MB) TX bytes:107283334 (107.2 MB)wlan0 Link encap:Ethernet HWaddr 00:27:xxxxxxxxx
inet addr:10.0.20.17 Bcast:10.0.20.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 -
Hmm, but not in the same subnet. What happens if you turn off the wifi before you connect the Ethernet?
I would check the routing table on the client, it seems like it just lost it's default route.Steve
-
Yep realized the subnet thing - eventually.
if wifi turned off first the only ip is the ethernet 10.0.0.0/24States for all when attempting to connect to dnsleaktest.com via ip address of (and filtered for that ip) 23.239.16.110 from firefox
LAN tcp 10.0.0.19:52364 -> 23.239.16.110:80 CLOSED:SYN_SENT 6 / 0 360 B / 0 B
VPN_WAN2 tcp 10.0.0.19:52364 -> 23.239.16.110:80 SYN_SENT:CLOSED 6 / 0 360 B / 0 B
LAN tcp 10.0.0.19:52370 -> 23.239.16.110:80 CLOSED:SYN_SENT 5 / 0 300 B / 0 B
VPN_WAN2 tcp 10.0.0.19:52370 -> 23.239.16.110:80 SYN_SENT:CLOSED 5 / 0 300 B / 0 B
LAN tcp 10.0.0.19:37646 -> 23.239.16.110:443 CLOSED:SYN_SENT 5 / 0 300 B / 0 B
VPN_WAN2 tcp 10.0.0.19:37646 -> 23.239.16.110:443 SYN_SENT:CLOSED 5 / 0 300 B / 0 B
LAN tcp 10.0.0.19:37648 -> 23.239.16.110:443 CLOSED:SYN_SENT 5 / 0 300 B / 0 B
VPN_WAN2 tcp 10.0.0.19:37648 -> 23.239.16.110:443 SYN_SENT:CLOSED 5 / 0 300 B / 0 BARP routing table
VLAN_10_OPT4 10.0.10.11 18:e8:xxxxxxx:8b AP200 Expires in 604 seconds vlan
WAN 73.245xx 18:8b:xxx:xx:28:xx c-73-245xxx.hsd1.fl.comcast.net Expires in 157 seconds ethernet
WAN 73.245.92.xx 00:1b:21:ba:xxxx c-73-xxx-9xxxx.hsd1.fl.comcast.net Permanent ethernet
VLAN_20_OPT5 10.0.20.12 34:a3:95:88:xxxc iPhone Expires in 1165 seconds vlan
VLAN_20_OPT5 10.0.20.11 60:f4:45xxxx iPhone.localdomain Expires in 1146 seconds vlan
LAN 10.0.0.10 00:1b:21:xxxxxxx pfSense.localdomain Permanent ethernet
LAN 10.0.0.19 f0
f1:0dxxxxx user-ThinkPad-T410.localdomain Expires in 1176 seconds ethernet
VLAN_20_OPT5 10.0.20.16 04:52:f3:8xxxx users-iPad Expires in 1173 seconds vlan
VLAN_40_OPT7 10.0.40.1 00:1b:21xxxxxx Permanent vlan
VLAN_30_OPT6 10.0.30.1 00:1b:21xxxxxx Permanent vlan
VLAN_30_OPT6 10.0.30.10 00:27:10:8xxxx Expires in 623 seconds vlan
VLAN_20_OPT5 10.0.20.1 00:1b:21:bxxxxxx Permanent vlan
VLAN_10_OPT4 10.0.10.1 00:1b:21:xxxxxxxx Permanent vlan
IGB3 10.0.50.1 00:1b:2xxxxxx -
You know multihoming devices with both ethernet and wireless at the same time is normally not a good idea... This is why its common for the wifi interface to turn off when connected to a wire... This is very common in laptops. Generally multihoming devices be it wired/wired wireless/wireless or wired/wireless is normally not good setup.
If not directly supported in the wifi driver you can do it like this
https://www.dell.com/support/article/us/en/19/how11386/how-to-disable-a-wireless-network-connection-when-a-wired-connection-is-detected?lang=enlinux has multiple options for doing this as well.
Yes normally the routing metrics will have the box prefer the wired connection since it should be faster, etc.
-
Thanks. Most of this is above my pay grade and trying to learn as much as I can to get the box working as I want.
Took some time to realize that the wifi was still connecting even though the Wicd network manager was only saying wired connection - would have helped if Id looked at ifconfig full results rather than just eth0As it stands, (wired connection to LAN, wifii off) seems no matter how I fiddle with the rules there is nothing coming in on a browser page, though ipcm pings are ok from the linux client and from within the pfsense ping window
The vlans and openvpn are all working as they should - just the LAN that wont play
-
well "lan" default rules are any any - did you mess with that?... Can you ping pfsense lan IP? What is the clients route table when only connected the lan... You have pfsense set as your gateway?
What is being handed out for dns when only on the wired lan?
-
OK – A bit confused here and apologies for my lack of understanding, but can ping to 10.0.0.10 which is the webconfig addresss
Can ping to say 9.9.9.9 form client linux pc wired to LAN.
And also from inside pfsense ping window
dhcp on psfense giving addesses as setLAN rules have been set the same as rules in the VLAN20 (OPENVPN) subnet as I wanted the same results (could be totally screwed up her thru a lack of understanding)
Removing all those rules and just having allow all to all makes no difference except it stops ping from my linux client pc – which I didn’t understand as I thought all meant everything?Getting routes for igb1 (LAN interface) not set as gateway – default gateway as set by pfsense
Unsure what client route table was unless its
Destination Gateway Flags Use Mtu Netif Expire
10.0.0.0/24 link#2 U 656 1500 igb1Additionally, was not sure how to see “What is being handed out for dns when only on the wired lan?”
Another strange thing, when connected to an windows7 PC still no web pages but windows reports the connection has internet - so could some ports or protocol be blocked? Tho 80 and 443 are allowed ports. And the subnets and ports are fine on the VPN subnet -
there should be a default route..
Your on linux right? what does netstat -rn show?
root@uc:/tmp# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.2.253 0.0.0.0 UG 0 0 0 ens3 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ens3 root@uc:/tmp#windows would be
route print from cmd lineas to what your using for dns.. you can normally look in /etc/resolv.conf
are you using the network manager gui? It should show you what using.
As to your rules not sure what you then think that vpn_wan2 address is ever going to be a source of traffic into your lan interface
-
The dns is from the isp provider either comcast or the VPN not set on the connection cant seem to get it to respond to a set dns in pfense setup
I thought the vpn_wan2 address rule would route the lan thru the VPN - but as I said am out of my depth here
netstat.....user@user-ThinkPad-T410 ~ $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.0.0.10 0.0.0.0 UG 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 user@user-ThinkPad-T410 ~ $ -
If you can ping 9.9.9.9 from the client then the routes are good.
That 'wan out' rule is almost certainly wrong on the LAN interface. You should never see traffic sourced from the VPN_WAN2 address arrive at the LAN interface.
The only rule that can pass a connection to a general website in the unlabelled rule. That is passing everything via the VPN gateway. There are no states shown on it though. It looks like no traffic is hitting that.
Steve
-
not sure why you would have that 169.254 address there.. APIPA??? you shouldn't have that - but its not going to hurt anything.
But don't see any hits on your rules going anywhere..
Are you running pfblocker? That runs a vip on your lan and can mess with your ! rule you have their with the local subnets that should allow access out to the internet... But its forcing traffic out your vpn.
-
@stephenw10
Thanks
Ive disabled all the rules on LAN except lockout and a new rule IvP4 allow all to all
ping still gets reply but no other sign of internet via wired LAN (with client VPN disabled and running same result)
I did notice when connected to windows7 which I have\ dual boot with linux that windows reports there in an internet connection tho no web pages are avaialble. -
@johnpoz
Thanks, Ive no idea where the 192.254 is coming from - it only appears when wired LAN connected, nothing visible in network settings manager.Not running pfblocker or any addon (gave upon pfblocker on an other Atom 2.4g box as it seemed to be causing the cpu to run at between 80-100% and couldn't find a fix)
With no rules other than anitlockout and a pass all to all rule on LAN no webpages are getting thru but ICMP is fine
-
Are you running proxy?
Those 169.254 can often show up when you have set for dhcp but don't get an address..
Does any box on your wired lan work? Do you see devices in your dhcp lease table on your lan? Do you have any floating rules?
Your rules are forcing traffic out your vpn!! Do you see hits on the rules? What does your outbound nat look like if your trying to send traffic out a vpn.
Why don't you make your rules any any - default out of the box on lan... And now do something as simple as a wget on your linux box to say www.google.com... Does it grab anyway.
-
No, no proxy
wget via lan is not resolved - I'm thinking its a dns issue on the lan
perhaps the dns resolver and forwarder settings for the vlans, which I think prevent dns lookup when the vpn is down is preventing dns resolving on the lan.
From inside pfsense the dns lookup is ok and comes from the settings in general setupI'm trying to recreate this https://nguvu.org/pfsense/pfsense-baseline-setup/ but there is no lan in the description.
Is there a way to give the lan dns servers without affecting anything else? That is, if that's the issue as the vlans work well.
-
out of the box pfsense resolver will listen on all interfaces... But your rules don't even allow your client to talk to pfsense - since your shoving everything out your vpn!
Remove that policy route.. And allow for lan to talk to pfsense lan IP tcp/udp port 53 Directly query pfsense lan IP for something.. Does it resolve?
use dig or host or nslookup on your client - pointing directly to pfsense lan IP.
Well maybe you do - but you have alias for both source and dest on the rule that might allow it.
-
Thanks for all of the help!
I changed the lan interface nic assignment just in case it had some problem (no idea if that's a possibility as icmp was running ok but anyways things seemed intermittent - sometimes ping to google.com was resolved then ping to say bbc.co.uk was not resolved and no names were found - all the time ping to number address worked -.9.9.9.9. for eg.
Ping and dns lookup always work from inside the pfsense box.Removed all rules on lan except allow all to all - rebooted a few times, changed cables - restarted client pc and set new connection to run
And.... the thing came to life with www available.
Thanks again this forum is a great resource!!
