DHCP Vlan ISP

[s_serra]

I am obtaining a public IP address via DHCP on the wan interface. On the wan interface I put vlan 12 since my ISP provides IP addresses in this vlan. I have a problem and it's that after some time I have no internet connection and the ping to getway goes offline. It seems that dhcp does not want to assign any more ip addresses even when I release the wan. I don't know if it could be pfsense or my ISP that is blocking it.

Does anyone have any idea what it could be?

Compliments

[stephenw10]

Is it always the same amount of time?

Is anything logged in the pfSense system logs?

Does the gateway address still exist in the ARP table when it fails?

Steve

[s_serra]

@stephenw10

No, sometimes it takes about 30 minutes - 1 hour to stop having internet, other times it takes 5 minutes. I turn off pfsense for a while (1 hour) and when I turn it back on I get the same IP address (188.80.151.234) obtained previously.

I currently have internet and my arp table looks like this.

[stephenw10]

Ok so see if it fails when that ARP table entry for the gateway IP expires or before that.

[s_serra]

@stephenw10

I waited until I ran out of internet again. All the prints I'm going to send below were when I was without internet. I lost internet at 3:36 pm (15:36) in Portugal. Pfsense obtained the ip via dhcp at 15:12. He ran out of internet 7 minutes before completing the 30 minutes.

ARP table (without internet):

System logs:

Gateway logs:

Interfaces status (without internet):

DHCP client logs:

Arp table expired gateway:

[stephenw10]

Hmm that first screenshot above shows exactly the same expiry times as when you did have internet. Is that a mistake?

What do you have to do to restore the connection?

Do you have any NICs other than Realtek? It could just be the NIC stops passing traffic.

Steve

[s_serra]

@stephenw10

Yes, I sent the wrong print, I have already updated it.

To get internet back I have to turn off pfsense for about an hour to get internet back.

They're the only ones I have. My desktop is also Realtek.

[stephenw10]

Hmm, well I don't see any watchdog timeouts logged for the Realtek NIC but that doesn't mean it's definitely not just failing.

You might try reassigning the WAN as the other NIC in case its that device specifically.

Also try anything else that might restore the connection like replugging the WAN cable or running ifconfig re0 down; ifconfig re0 up. If it can only be restored by power cycling the NIC it's probably a hardware issue.

Steve

[s_serra]

@stephenw10

Removing and inserting the cable didn't work and the commands on the terminal didn't work either. What I said about having to wait an hour to get the IP address again is a lie. If you disconnect the power and turn it back on, you will immediately get the address and you will have internet again.

I was on D1 and now I changed to D2 and the problem no longer seems to happen. But I needed to have pfsense connected directly to the ONT since pfsense and the router are in very distant locations.

The IP obtained through DHCP is the same

[s_serra]

@s_serra

In D2 the DHCP logs are:

Everything is working perfectly but I needed pfsense connected directly to the ONT.

[stephenw10]

Ah so both pfSense and the ISP router are pulling IPs from the ISP in the D1 setup. That's not normally allowed, an ISP would usually only provide one IP address.

Why do you need pfSense connected to the ONT directly?

Why do you need the ISP router at all?

[s_serra]

@stephenw10

For two reasons. The ISP's router and the other router will be in distant locations and they didn't want to have both connected as the distance is too far. I will have two networks, one for the servers and one for home. I need ISP's router because of IGMP and VOIP.

I tried turning off the ISP's router, leaving only pfsense on and even then, after a while, pfsense no longer has an IP address.

A user from my ISP made a tutorial on how to use pfsense connected directly to the ONT but it is in Portuguese.

https://forum.meo.pt/internet-fixa-e-movel-11/tutorial-pfsense-87365

An interesting point. In D1 without the ISP router (and without a switch, a test to see if it could be the switch but that wasn't the problem), that is, the RJ45 cable connected directly from the ont to the pfsense, I restarted the pfsense normally without turning off the power and the pfsense after the reboot does not pick up IP but if I remove the power cable and return Putting it on immediately and pfsense boots much faster.

The only problem that I am detecting could be that the vlan is directly associated with the wan port and could be causing some conflict but it is just an assumption since without the vlan with the bridge option on the ISP router it always works without problems.

[s_serra]

@s_serra

It doesn't seem to be from my ISP's DHCP server. pfsense has now been on for about 45 minutes and has made the IP renewal request twice without a problem. Here he got the IP address and after about 5 minutes it stopped showing.

I then removed the power cord and got the address again at 11:05.

[stephenw10]

@s_serra said in DHCP Vlan ISP:

https://forum.meo.pt/internet-fixa-e-movel-11/tutorial-pfsense-87365

Hmm, nothing complex in that tutorial. Just the VLAN required. Or at least it was in 2016!

The behaviour you're observing though seems to imply the ISP router s doing something more that pfSense is not.

[s_serra]

@stephenw10

I changed the inputs, lan to wan and wan to lan and so far I've had almost 3 hours with the internet always working. The port that was on the wan that I must now use on the lan does not seem to be causing problems on the local network.

[s_serra]

@s_serra

How can I be sure the problem is with the port?

[stephenw10]

Well if the only change you made was to switch the NIC assignments that seems like a fair conclusion.

Are the NICs actually identical? Same device IDs in pciconf -lv?

[s_serra]

@stephenw10

Yes, I think the nics are the same. It's a nuc with nics built into the motherboard.

hostb0@pci0:0:0:0:	class=0x060000 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f00 subvendor=0x8086 subdevice=0x0f31
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register'
    class      = bridge
    subclass   = HOST-PCI
vgapci0@pci0:0:2:0:	class=0x030000 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f31 subvendor=0x8086 subdevice=0x0f31
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series Graphics & Display'
    class      = display
    subclass   = VGA
atapci0@pci0:0:19:0:	class=0x01018a rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f21 subvendor=0x8086 subdevice=0x0f21
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800 Series SATA IDE Controller'
    class      = mass storage
    subclass   = ATA
xhci0@pci0:0:20:0:	class=0x0c0330 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f35 subvendor=0x8086 subdevice=0x0f35
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI'
    class      = serial bus
    subclass   = USB
none0@pci0:0:26:0:	class=0x108000 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f18 subvendor=0x8086 subdevice=0x0f18
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine'
    class      = encrypt/decrypt
pcib1@pci0:0:28:0:	class=0x060400 rev=0x0e hdr=0x01 vendor=0x8086 device=0x0f48 subvendor=0x8086 subdevice=0x0f48
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800 Series PCI Express Root Port 1'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:28:1:	class=0x060400 rev=0x0e hdr=0x01 vendor=0x8086 device=0x0f4a subvendor=0x8086 subdevice=0x0f4a
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800 Series PCI Express Root Port 2'
    class      = bridge
    subclass   = PCI-PCI
pcib3@pci0:0:28:2:	class=0x060400 rev=0x0e hdr=0x01 vendor=0x8086 device=0x0f4c subvendor=0x8086 subdevice=0x0f4c
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800 Series PCI Express Root Port 3'
    class      = bridge
    subclass   = PCI-PCI
pcib4@pci0:0:28:3:	class=0x060400 rev=0x0e hdr=0x01 vendor=0x8086 device=0x0f4e subvendor=0x8086 subdevice=0x0f4e
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800 Series PCI Express Root Port 4'
    class      = bridge
    subclass   = PCI-PCI
ehci0@pci0:0:29:0:	class=0x0c0320 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f34 subvendor=0x8086 subdevice=0x0f34
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series USB EHCI'
    class      = serial bus
    subclass   = USB
isab0@pci0:0:31:0:	class=0x060100 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f1c subvendor=0x8086 subdevice=0x0f1c
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series Power Control Unit'
    class      = bridge
    subclass   = PCI-ISA
ichsmb0@pci0:0:31:3:	class=0x0c0500 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f12 subvendor=0x8086 subdevice=0x0f12
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800/CE2700 Series SMBus Controller'
    class      = serial bus
    subclass   = SMBus
re0@pci0:3:0:0:	class=0x020000 rev=0x07 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
re1@pci0:4:0:0:	class=0x020000 rev=0x06 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet

[stephenw10]

Yup seems identical at that end at least. They could have different PHYs potentially. Hard to say why it should behave differently.

[s_serra]

@stephenw10

Thanks a lot for the help.