Yes, I know! Another OPT1 and OPT2 no internet connection!
-
@w0w
Services/DHCP pages are the same for LAN, OPT1 and OPT2 with only the ip's being different, reflecting the three different subnets. -
@MidGe48 said in Yes, I know! Another OPT1 and OPT2 no internet connection!:
@w0w
Services/DHCP pages are the same for LAN, OPT1 and OPT2 with only the ip's being different, reflecting the three different subnets.Did you try to restore some saved known working config? I wouldn’t be surprised that some detail was missed.
Can clients connected to OPT1 and OPT2 ping pfSense when you have set a static IP address on the client itself? -
@MidGe48 said in Yes, I know! Another OPT1 and OPT2 no internet connection!:
And my computer on that subnet does not get an ip eithe
Well no wonder dns fails.. Nothing is going to work if your device doesn't have an IP. How would you query for dns if you have no IP?
And if the device on opt1 or opt2 is not getting an IP from dhcp. Doesn't even matter if you had put the correct rules on opt1 and 2..
You need to make sure the device is getting an IP before you could even look to rules not being correct on the interface, or if dns was running, etc.
If you did a clean install on a 2100, the ports would all switch back to the lan via the switch?
https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/configuring-the-switch-ports.html
-
Hi Johnpoz,
The answer you give is not relevant. I am not setting VLAN's at all. These ports [OPT1 and OPT2] are for discreet physical LAN networks.
The docs page that is relevant for this is https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/opt-lan.html.
But thanks for trying to help. I may not have been clear enough in my original post.
-
@MidGe48 said in Yes, I know! Another OPT1 and OPT2 no internet connection!:
These ports [OPT1 and OPT2] are for discreet physical LAN networks.
And since your on a switch, you would have to set those up in the switch to be discrete.. Which the link I posted.
The 2100 has a switch, they default to all being the lan, if you want to break out ports to be discrete - you have to set them up to do that..
if your not using a 2100, my bad and I apologize - maybe I confused this thread with another one.. Not sure where I got you were using a 2100??
-
@johnpoz said in Yes, I know! Another OPT1 and OPT2 no internet connection!:
2100
Is this a 2100?
Does it work if you don't use Kea?
-
Unfortunately no saved configs. I though that with a fresh install I would have no need and deleted them as soon as I thought everything was working fine.
I am going to give it one more try with a fresh install, if that fails, I will have to look into some alternatives, which is a pity as after a few years, I was quite conversant with ipSense which had been running very solidly.
-
@stephenw10 said in Yes, I know! Another OPT1 and OPT2 no internet connection!:
Is this a 2100?
That might have been my bad Steve - not sure where I got he was on a 2100.. Looking over the thread I don't see where he stated that.. Doh!!
-
-
@MidGe48 well if its discrete and your not getting an IP from dhcp, then either dhcp is not running on that interface? Or your connection isn't valid.
You validated dhcp is running and listening on that interface.. Does it log show anything from client(s) on this network.. Dhcp would work with zero rules on the interface, because when you enable dhcp hidden rules are created that allow for dhcp.
So either dhcp is not running, or its not seeing any requests/discovers. etc.. or it doesn't have any leases available?
Other possible thing - you sure your assigned to the correct interfaces on the box? Does the interface show up when you plug in your device or switch?
-
Ok, managed to install a last known working configuration.
Unfortunately , the interfaces for OPT1 and OPT2 show "autoselected" but disable (red cross) on the gui.
Also when restoring from backup, the packages that were installed are not. When I go to package manager, it shows none installed and when I go to available packages it shows me "Unable to retrieve package information.".
That being said, the LAN port works and devices connected to it can access the internet, etc.
I am now wondering, if OPT1 and OPT2 are borked. Although it is quite unlikely to have two ports borked simultaneously and the third (LAN) and fourth (WAN) not.
I am not sure how to test whether there is a hardware fault on these ports. The lights at the connection are on (unblinking of course).
-
Run
ifconfigat the command line and see which NICs are actually linked. Unplug one of the OPT ports and make sure the one that goes down if what you think it is. -
Some progress being made.
On my test (for this exercise) machine running Linux. Changing the connection type from "Automatic (DHCP)" to "Automatic (DHCP) addresses only" the bringing eth0 down and back up and it connects correctly and gets an ip address, of course. That is all on a working version before last upgrade and before switching to Kea.
So, now the issue is that one of the failing interfaces connect all sorts of IOT and media devices that I do not want to get into other subnets on my network (paranoia about privacy :) ). I am not sure if can change the way they request a DHCP connection. Or I may need change the way the DHCP server handles that. But there must have been a change very recently because I have had no such issues for a few years at least with my current network topology.
But thanks all for your help.
-
@MidGe48 said in Yes, I know! Another OPT1 and OPT2 no internet connection!:
but disable (red cross) on the gui.
What would your client dhcp setting have to do with an interface not coming up? Make no sense.. If you connect something to that interface it should come up.. Regardless what dhcp or bootp or whatever protocol you might want to be using for dhcp, maybe the client is static.. None of that has anything to do with the interface coming up on your router.
Maybe just the bounce on the client interface is what brought up the interface on the router, that would make more sense then what you set its dhcp client to do.
-
Since that last message and restoring a two month old backup, the interface comes up on the router as per my previous post.
Still have problems with the clients not being to connect unless I change the connection type on the client. This is possible on my Linux machines but a lot of IOT devices I use do not have that facility and do not connect readily, or connect but get no internet (DNS issue, I guess).
Note that all of this started happening after a complete new install of pfSense, following a crash whilst moving to the new Kea DHCP as suggested on the GUI.
It has now taken me three days in trying to resolve this issue. Three days, given my age, likely to be a too big proportion of the rest of my live. It may be alright for most, or youger ones, but its too long for me. I came to pfSense a number of years ago after experiencing too many crashes with Opnsense. I think I may have to start looking at another alternative.
-
@MidGe48 said in Yes, I know! Another OPT1 and OPT2 no internet connection!:
(DNS issue, I guess)
Don't guess. Be sure ;) Some tests :
When you start pfSense, the console shows a lot of useful info.
Like these :.... igc0: <Intel(R) Ethernet Controller I225-V> mem 0x81300000-0x813fffff,0x81400000-0x81403fff at device 0.0 on pci4 ... igc1: <Intel(R) Ethernet Controller I225-V> mem 0x81100000-0x811fffff,0x81200000-0x81203fff at device 0.0 on pci5 ... igc2: <Intel(R) Ethernet Controller I225-V> mem 0x81100000-0x811fffff,0x81200000-0x81203fff at device 0.0 on pci5 ....etc.
I have the "igc" family of network cards, yours might be different. Like 'em'. These lines mean : the kernel found the hardware.These found interfaces have to be assigned in the GUI :
When booted into pfSense, go console, or SSH - option 8 :
Check what processes are using (listening) on port 67 (DHCP):
[23.09-RELEASE][root@pfSense.bhf.tld]/root: sockstat -4l | grep ':67' root kea-dhcp4 23282 19 udp4 192.168.1.1:67 *:* root kea-dhcp4 23282 21 udp4 192.168.2.1:67 *:* root kea-dhcp4 23282 23 udp4 192.168.100.1:67 *:*As I have 3 LANs on pfSense, 192.168.1.1/24, 192.168.2.1/24 and 192.168.100.1/24, and these 3 LANs are being set up on my pfSense using "DHCP-server" - or, actually KEA (same thing for me) I know on the pfSense side all is ok.
The same test can be done for the resolver (unbound) (note that I'm testing for IPv4 and IPv6 now :
[23.09-RELEASE][root@pfSense.bhf.tld]/root: sockstat -l | grep ':53' unbound unbound 63341 3 udp6 *:53 *:* unbound unbound 63341 4 tcp6 *:53 *:* unbound unbound 63341 5 udp4 *:53 *:* unbound unbound 63341 6 tcp4 *:53 *:*which means : for all interfaces (yep, even WAN), for both IPv4 and IPv6, both TCP and UDP ( ! ) unbound listens on port '53'.
If DNS traffic doesn't reach unbound on pfSEnse now, then this can be only one reason : a firewall rule on the interface blocks TCP or UDP port 53 traffic - that this interface.
I presume you don't use smart-switches or something like that.
-
Hello Gertjan,
OK, I did what you suggested.
-
On the GUI i have all the interface assignment showing with the correct (I hope) network port.
-
There are NO processes using or listening on port 67
-
The resolver (unbound) shows me a single process for tcp4 and udp4. I have disable ipv6 everywhere so I suppose this is correct.
The issue now, is with having no processes listening on port 67! But, now that I have reverted to a backup of two months ago when everything was dandy, I am not using Kea at the moment.
I am using unmanaged switches, so that should not be an issue.
Thanking you very much for trying to help me.
-
-
My boot log shows the ports working as well, I presume:
igb3: netmap queues/slots: TX 4/1024, RX 4/1024
igb3: Ethernet address: 00:e0:67:21:65:5f
igb3: Using MSI-X interrupts with 5 vectors
igb3: Using 4 RX queues 4 TX queues
igb3: Using 1024 TX descriptors and 1024 RX descriptors
igb3: NVM V0.6 imgtype6
igb3: <Intel(R) I210 Flashless (Copper)> port 0xb000-0xb01f mem 0xb1200000-0xb121ffff,0xb1220000-0xb1223fff irq 19 at device 0.0 on pci4
pci4: <ACPI PCI bus> on pcib4
pcib4: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
igb2: netmap queues/slots: TX 4/1024, RX 4/1024
igb2: Ethernet address: 00:e0:67:21:65:5e
igb2: Using MSI-X interrupts with 5 vectors
igb2: Using 4 RX queues 4 TX queues
igb2: Using 1024 TX descriptors and 1024 RX descriptors
igb2: NVM V0.6 imgtype6
igb2: <Intel(R) I210 Flashless (Copper)> port 0xc000-0xc01f mem 0xb1300000-0xb131ffff,0xb1320000-0xb1323fff irq 18 at device 0.0 on pci3
pci3: <ACPI PCI bus> on pcib3
pcib3: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
igb1: netmap queues/slots: TX 4/1024, RX 4/1024
igb1: Ethernet address: 00:e0:67:21:65:5d
igb1: Using MSI-X interrupts with 5 vectors
igb1: Using 4 RX queues 4 TX queues
igb1: Using 1024 TX descriptors and 1024 RX descriptors
igb1: NVM V0.6 imgtype6
igb1: <Intel(R) I210 Flashless (Copper)> port 0xd000-0xd01f mem 0xb1400000-0xb141ffff,0xb1420000-0xb1423fff irq 17 at device 0.0 on pci2
pci2: <ACPI PCI bus> on pcib2
pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.1 on pci0
igb0: netmap queues/slots: TX 4/1024, RX 4/1024
igb0: Ethernet address: 00:e0:67:21:65:5c
igb0: Using MSI-X interrupts with 5 vectors
igb0: Using 4 RX queues 4 TX queues
igb0: Using 1024 TX descriptors and 1024 RX descriptors
igb0: NVM V0.6 imgtype6
igb0: <Intel(R) I210 Flashless (Copper)> port 0xe000-0xe01f mem 0xb1500000-0xb151ffff,0xb1520000-0xb1523fff irq 16 at device 0.0 on pci1
pci1: <ACPI PCI bus> on pcib1
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0 -
Good news : your device has supported network hardware.
Not really a surprise, as it worked before.Btw : you are using the pfSense CE 2.7.1, right ?
What did the sockstat test show ?
-
Yes, using pfSense CE 2.7.1
On the GUI i have all the interface assignment showing with the correct (I hope) network port.
There are NO processes using or listening on port 67
The resolver (unbound) shows me a single process for tcp4 and udp4. I have disable ipv6 everywhere so I suppose this is correct.
