OPNsense Forum
Archive => 22.1 Legacy Series => Topic started by: nemric on January 27, 2022, 09:22:44 pm
-
Hi,
I've upgraded today for the new release, and my vlan vlan don't go online.
my config :
vlan100 on em1
assigned to an interface with options :
- spoof mac : xx:xx:xx:xx...
- send option : vendor-class-identifier "BYGTELIAD"
I've run a packet capture and only options :
53 DHCP message
50 requested ip
61 client identifier
12 host name
55 parameter request list
255 END
are sent
Option 60 vendor-class-identifier is missing
It was working like a charm before upgrade so it seems that it's a regression
-
I think I’m seeing the same issue with a remote connection in France which I upgraded over VPN
No IP is allocated which suggest the send options are not being passed as Orange France have special options in order to grant an IP
As I’m remote I can’t wire shark the output
Thankfully I have a failover connection so can apply any patch/upgrade to fix it
-
For my VLAN firewall rules, I found I had to remove the 'gateway' associated with the 'allow any' rule for traffic to correctly flow outside my network from said VLAN.
-
It’s not firewall rule on vlan that’s the issue it’s the option not being passed when a dhcp request is made to the isp servers
-
I can't believe it's true....
I went back to 21.7.8 (and VLAN is up) and I've made a packet capture for dhcp
The captures are the same execpt for 1 thing :
option (53) DHCP Message Type is discover for v22.1
option (53) DHCP Message Type is request for v21.7
in both cases I can't see option 60 vendor-class-identifier :/
I've removed this option (vendor-class-identifier "BYGTELIAD") from interface settings and it works :/
I won't have more time today to investigate deeper, see you later
-
when you say it works I assume only at 21.7 NOT at 22.1
-
you're right, I'm now back to 21.7
-
Did you have to re-image to do that. I'm remote so only have a failover connection to gain access
-
Yes I had to reinstall form an USB key. I didn't find any way to downgrade
-
The dhclient looks like the default FreeBSD one, not the one that was modified to work with OR France etc.
-
@nemric - Seems the version from 21.7 is working OK, at least on my test device so I'm attaching it here. No guarentees, but try it. At least you have a local device and can revert. @nivek1612 is concerned he might lose everyhing if he tries, so would you try it and let us know? Remember to set the permissions to 0555 after copying the attached to /sbin .
-
I am having Internet access issues post 22.1 upgrade. I did a tcpdump on the WAN interface when connecting to my ISP. A DHCP address is being offered and accepted but I get no traffic. Can't ping, nothing is getting out. Strange..
-
> The dhclient looks like the default FreeBSD one, not the one that was modified to work with OR France etc.
Well yes and no. The relevant change should be emulated by https://github.com/opnsense/src/commit/50ecd99be523 but I make no claim it works as intended as it's not our work.
Having both the upstream commit and our old modification was an impossible situation.
Might also be another change upstream that interferes. Nobody seems to have looked closely enough with the setup at hand.
Cheers,
Franco
-
Yes I can see it... came from over the road. IIRC ours had a bit more to it than that. Can you point me at the changes we made to dhclient and I'll have a looksee tomorrow.
-
I am having Internet access issues post 22.1 upgrade. I did a tcpdump on the WAN interface when connecting to my ISP. A DHCP address is being offered and accepted but I get no traffic. Can't ping, nothing is getting out. Strange..
If you are getting a WAN v4 address, then it's not the client causing you issues. Try some deeper diagnostics from the WAN interface, ping 8.8.8.8 for example, if that works then try a ping to www.google.com, that will prove if the dns ( unbound ) is working. My test system which is running 22.1 is working fine, and it's a simple dual stack setup.
-
@nemric - Seems the version from 21.7 is working OK, at least on my test device so I'm attaching it here. No guarentees, but try it. At least you have a local device and can revert. @nivek1612 is concerned he might lose everyhing if he tries, so would you try it and let us know? Remember to set the permissions to 0555 after copying the attached to /sbin .
Hi, I'm not sure to understand what you ask me for.
I'm running 21.7 now, and my vlan100 get an ip from ISP and everything works fine
The file you want me to try is for 22.1 ?
-
I am having Internet access issues post 22.1 upgrade. I did a tcpdump on the WAN interface when connecting to my ISP. A DHCP address is being offered and accepted but I get no traffic. Can't ping, nothing is getting out. Strange..
If you are getting a WAN v4 address, then it's not the client causing you issues. Try some deeper diagnostics from the WAN interface, ping 8.8.8.8 for example, if that works then try a ping to www.google.com, that will prove if the dns ( unbound ) is working. My test system which is running 22.1 is working fine, and it's a simple dual stack setup.
Pinging the GW fails. Interface info and failure below
igb0_vlan10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: WAN
options=4000400<LRO,NOMAP>
ether d4:a9:28:14:e8:98
inet6 fe80::d6a9:28ff:fe14:e898%igb0_vlan10 prefixlen 64 scopeid 0x6
inet 108.20.117.101 netmask 0xffffff00 broadcast 108.20.117.255
groups: vlan
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: igb0
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Guest (igb0_vlan200) -> v4: 192.168.200.30/27
LAN (igb0_vlan100) -> v4: 192.168.1.254/24
PIAWG (wg0) -> v4: 10.7.154.210/8
WAN (igb0_vlan10) -> v4/DHCP4: 108.20.117.101/24
PING 108.20.117.1 (108.20.117.1): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
-
Yes please, if you can run up 22.1 and then copy the dhclient over to that and reboot, see if it works... if not then we need to look elsewehere for the issue, but I suspect that it's the client.
@nemric - Seems the version from 21.7 is working OK, at least on my test device so I'm attaching it here. No guarentees, but try it. At least you have a local device and can revert. @nivek1612 is concerned he might lose everyhing if he tries, so would you try it and let us know? Remember to set the permissions to 0555 after copying the attached to /sbin .
Hi, I'm not sure to understand what you ask me for.
I'm running 21.7 now, and my vlan100 get an ip from ISP and everything works fine
The file you want me to try is for 22.1 ?
-
Are you on OR France as well?
I am having Internet access issues post 22.1 upgrade. I did a tcpdump on the WAN interface when connecting to my ISP. A DHCP address is being offered and accepted but I get no traffic. Can't ping, nothing is getting out. Strange..
If you are getting a WAN v4 address, then it's not the client causing you issues. Try some deeper diagnostics from the WAN interface, ping 8.8.8.8 for example, if that works then try a ping to www.google.com (http://www.google.com), that will prove if the dns ( unbound ) is working. My test system which is running 22.1 is working fine, and it's a simple dual stack setup.
Pinging the GW fails. Interface info and failure below
igb0_vlan10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: WAN
options=4000400<LRO,NOMAP>
ether d4:a9:28:14:e8:98
inet6 fe80::d6a9:28ff:fe14:e898%igb0_vlan10 prefixlen 64 scopeid 0x6
inet 108.20.117.101 netmask 0xffffff00 broadcast 108.20.117.255
groups: vlan
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: igb0
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Guest (igb0_vlan200) -> v4: 192.168.200.30/27
LAN (igb0_vlan100) -> v4: 192.168.1.254/24
PIAWG (wg0) -> v4: 10.7.154.210/8
WAN (igb0_vlan10) -> v4/DHCP4: 108.20.117.101/24
PING 108.20.117.1 (108.20.117.1): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
-
The old one was https://github.com/opnsense/src/commit/5e4e4f842b714e
Looking at the config it should ignore vlan-parent and vlan-id so that vlan-pcp is still read and used. I've made sure to set net.link.vlan.mtag_pcp=1 on 22.1 for that reason.
One thing to try is to scrub vlan-parent and vlan-id from the configuration, but I worked on compatibility with defunct options including submitting it to FreeBSD so I would rather assume the PCP is not set correctly?
Cheers,
Franco
-
No I am in the US and my carrier is Verizon FIOS. I don't think its a carrier issue since 22.1 fails in my lab just like it does with my provider.
-
No, I know it's not the ISP, just wondered if you were OR France.
No I am in the US and my carrier is Verizon FIOS. I don't think its a carrier issue since 22.1 fails in my lab just like it does with my provider.
-
@nemric let me know if you are unsure how to replace the dhclient file. I can help. I just don't want to try on my remote system in case it crashes the router. I will have no way back. Sitting next to it is very easy and risk free.
-
Hi,
I will give it a try tomorrow, I need internet today ^^
@marjohn56 my ISP is not OR france (presume it's orange) but like orange I need a VLAN to bypass the box.
-
@nemric - Seems the version from 21.7 is working OK, at least on my test device so I'm attaching it here. No guarentees, but try it. At least you have a local device and can revert. @nivek1612 is concerned he might lose everyhing if he tries, so would you try it and let us know? Remember to set the permissions to 0555 after copying the attached to /sbin .
I tested the dhclient you attached. While DHCP is working consistently for me with the new client it doesn't fix getting out to the internet. I still lose internet access with 22.1 and when I ping I get this error
root@crawford:~ # ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
while it is getting an IP address routing doesn't seem to be getting setup properly.. Let me know anything else you think I should test.
-
Yes please, if you can run up 22.1 and then copy the dhclient over to that and reboot, see if it works... if not then we need to look elsewehere for the issue, but I suspect that it's the client.
I finally make the image of 22.1 written on an USB key, see other post ...
What if I write your Dhclient on the USBkey to test it from live boot ? will the test be the same ?
To be honest I don't really want to update, test, reinstall(or not) and so on ^^ but I agree to make some test !
-
So, I tried to replace dhclient on the USB key and then try to boot on live OS
My Vlan didn't obtain any ip again, the pb seems to be elsewhere :(
-
Hmmm interesting
Did you remember to change the permissions of the dhclient after you copied it to the usb.
-
Maybe, just maybe this is about VLAN parent not being assigned now using hardware features that are not supported/broken? Try to assign the VLAN parent, enable it and see if that yields a response. From what I can see here and assuming dhclient does what it supposedly can the problem might be not there at all.
For reference see: https://github.com/opnsense/core/issues/5521
Cheers,
Franco
-
Hi Franco
So I tried that but no joy.
Added a new interface on igb0 called "VLAN Spoof"
Rebooted after save and apply
Still no IP
-
Kev, can you post or mail "ifconfig igb0" output for me?
Thanks,
Franco
-
root@home:~ # ifconfig igb0
igb0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: VLANSpoof
options=48520b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,NOMAP>
ether 00:0e:c4:d2:a4:f9
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@home:~ #
-
There's still a number of offloading stuff enabled on the parent:
<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,NOMAP>
Normally it should apply on its own after enabling VLANSpoof, saving and hitting apply configuration. If not we can try manually. Let me know.
-
I still have this set want me to switch it to disable
-
Worth a try, yes please.
-
Done still
no IP but now the interface looks like this
igb0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: VLANSpoof
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,NOMAP>
ether 00:0e:c4:d2:a4:f9
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
and the VLAN that connects to the ISP
igb0_vlan832: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: WAN
options=4000000<NOMAP>
ether 30:7c:b2:1f:79:7d
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
inet6 fe80::327c:b2ff:fe1f:797d%igb0_vlan832 prefixlen 64 scopeid 0x9
groups: vlan
vlan: 832 vlanproto: 802.1q vlanpcp: 0 parent interface: igb0
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
-
It's strange that it's stuck with "inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255". Wouldn't that mean dhclient already received an offer? Maybe the request isn't making it to the ISP?
Do we have a packet capture to look at?
Cheers,
Franco
-
Sure any particular setting you want in here
-
capture on vlanspoof with promisc, count not sure I just need the dhcp sequence... might be 100, might be 1000
send via mail
Thanks,
Franco
-
Yes I always have the pcap I've done when it fails.
I have changed my mac, Manufacturer_xx:xx:xx (xx:xx:xx:xx:xx:xx), the requested IP : Requested IP Address (123.123.123.123) and the hostname : hostname
-
@franco
capture on vlanspoof with promisc, count not sure I just need the dhcp sequence... might be 100, might be 1000
send via mail
Thanks,
Franco
you won't believe this. turned on capture. re saved WAN. now its shows an IP address but gateway monitor claims the interface is down. Still want the capture
-
tried a reboot now i have this next to WAN .... at a loss now
-
Yes, capture please :)
-
nemric: in your case the discover is never answered. have you had your VLAN parent assigned and enabled? it looks like the outgoing package is never received by the other end.
-
@franco Just emailed capture
-
nemric: in your case the discover is never answered. have you had your VLAN parent assigned and enabled? it looks like the outgoing package is never received by the other end.
::) vlan is assigned to a parent but as I don't need it the parent is disabled, that's my 21.7 config
-
Sure, now enable it. It will properly enforce hardware checksum settings (defaulting to off).
Cheers,
Franco
-
Hi,
So, I did it, and that didn't work but I have a clue !
you won't believe this. turned on capture. re saved WAN. now its shows an IP
Like Nivek, I turned on capture in promiscuous mode and I get an IP !
I was working with the live OS and the new dhclient from 22.1 (not the one you ask me to download)
-
The plot thickens... there is also a promisc option in WAN parent setting... Did you previously spoof the MAC on the VLAN?
Cheers,
Franco
-
https://github.com/opnsense/changelog/blob/8e903676527cc2f0eb6caa1695fe50ef885d1612/community/22.1/22.1#L193
-
English is not my native language so I'm not sure about this point.
The wan (em1) interface is disabled on 21.7 and have no mac spoofing in its conf
The vlan100 which parent is em1/wan (em1_vlan100) use the spoofed mac address in its config (Mac adress : This field can be used to spoof the MAC address of the interface. Enter a MAC address in the following format: xx:xx:xx:xx:xx:xx or leave blank if unsure. This may only be required e.g. with certain cable connections on a WAN interface.)
[edit] The mac address sent by dhclient is the good one, see it in the .cap file
-
Ok so I had a spoofed mac address on my VLAN interface.
If I add this mac address to the VLAN parent interface as well I get an IP address and all is working well.
Now to find out why ipv6 is broken Franco :-)
-
If I add this mac address to the VLAN parent interface as well I get an IP address and all is working well.
Is that how it should work ? What if you have another vlan with spoofed mac with the same parent ?
-
Is that how it should work ? What if you have another vlan with spoofed mac with the same parent ?
Yes, because previously the MAC was flushed from the VLAN to all siblings and parent which prevented the use of multiple MAC addresses across VLANs of the same parent.
https://github.com/opnsense/core/issues/5297
Similar things happened to media settings and hardware offloading features as they would overlap per sibling but only one could win in the system configuration.
That being said if you want to change the MAC of a VLAN you can do that but the parent will still see the traffic first and discard a wrong MAC so it either needs that same MAC address (automatic prior to 22.1 but clobbering all siblings as well as parent) or the promiscuous mode flag (new in 22.1)
Cheers,
Franco
-
Well, I don't understand everything as it become a bit technical...
The option I've choosen, as I'm writing through a 22.1 live os :
- enable wan interface, without any "IPv4-6 Configuration Type" (set to "none")
- enable Promiscuous mode on wan interface
- leave vlan interface with spoofed mac as is
let me know if you find my choice is fine or if you think I should have set the same mac on wan and vlan
-
Correct, although the promiscuous mode is for grabbing all traffic potentially slowing the NIC down. You only need this when you try to emulate multiple MAC addresses across VLANs over the parent.
I just tried in a fresh VM moving the spoofed MAC from the VLAN to the parent (deleting it from the VLAN) and the system automatically assigns the spoofed MAC to the VLANs. That would likely be the most common way to configure it on 22.1 and forward.
Cheers,
Franco
-
Thanks a lot @Franco for the time you spent for us ;)
-
No problem. Next up tomorrow is the other issue that Kev was seeing with the firewall not setting the VLAN priority from the firewall for DHCPv6...
Cheers,
Franco
-
Thanks a lot @Franco for the time you spent for us ;)
what are the proper steps in setting the spoof mac address on the parent? I don't see how to do it in the GUI.
-
Go to Interfaces: Assignments and select the VLAN parent and create a new interface with it. Go to the interface configuration and enable it. After that you can set media settings there and MAC address to spoof. Save. Last remove MAC from VLAN(s) and save + apply. It might need a reboot to reorder the MAC addresses when they were set upside down previously.
Cheers,
Franco
-
No problem. Next up tomorrow is the other issue that Kev was seeing with the firewall not setting the VLAN priority from the firewall for DHCPv6...
Cheers,
Franco
Let me know if you want remote access again and I’ll unlock the port :-)
-
Go to Interfaces: Assignments and select the VLAN parent and create a new interface with it. Go to the interface configuration and enable it. After that you can set media settings there and MAC address to spoof. Save. Last remove MAC from VLAN(s) and save + apply. It might need a reboot to reorder the MAC addresses when they were set upside down previously.
Cheers,
Franco
This worked for me.. BTW I did not have to reboot for this to take effect.. I am now happily running on 22.1.. Was this change documented in the 22.1 release notes (the ones I didn't read but will moving forward)?
-
It was documented but don’t beat yourself up I read them and still didn’t see/understand the implications
-
Is it OK to make these changes in 21.7.8 before moving to 22.1?
-
On 21.7.8 I tested adding the parent interface, setting the WAN spoofed MAC to the parent, removed the spoofed MAC from the WAN vlan interface. This worked without a reboot. There was a short pause in the network but nothing failed. I then successfully upgraded to 22.1 without issue. Thanks to everyone that worked on this.
-
@s4rs thanks nice to hear. that is a good idea. :)
For the DHCPv6 issue that users from Orange FR are having. This looks like a kernel problem and I have published a snapshot kernel for broader testing:
# opnsense-update -zkr 22.1-prio
(requires a reboot)
Cheers,
Franco
-
May I suggest adding a sticky to 22.1 forum about this. Could save clicks and time.
-
I did edit the migration notes a bit and pushed them to the server so they are being displayed during upgrade with the extended information.
https://github.com/opnsense/changelog/commit/3eab5a51434
Cheers,
Franco
-
I did edit the migration notes a bit and pushed them to the server so they are being displayed during upgrade with the extended information.
https://github.com/opnsense/changelog/commit/3eab5a51434 (https://github.com/opnsense/changelog/commit/3eab5a51434)
Cheers,
Franco
You expect people to read that too?
When all else fails... RTFM. :)
-
...oh, maybe we should have a wiki, too! :-D
-
More places nobody reads proactively and complains about documentation quality when things went wrong. Yay! :)
-
https://www.heise.de/ct/ausgabe/2013-17-Editorial-Schreib-s-ins-Wiki-2317558.html
scnr...
-
More places nobody reads proactively and complains about documentation quality when things went wrong. Yay! :)
you're rude, but this is real.
I've noticed changes about vlan and mac spoofing but advice was clear for me, mac spoofing only concern the interface where it was set ... in my case I leave it as is, this was an error
So now my issue is resolved, thanks to you, and doc is updated for being more complete, that's a good point !
Thanks again
-
I'm half-joking and I accept the reality we are in in this regard. It's fun. We get to create something useful while at it. Never perfect, but that's ok.
Cheers,
Franco
-
Do the notes show up when doing a console upgrade? I don't remember seeing them.
-
Well, I would not have thought the day would come when somebody asked for this after all these years. :)
For simplicity the console never did indicate which version you are going to update to during minor iterations and only for major upgrades the confirmation prompt (i.e. "22.1") was added to raise awareness for what you're going to do.
When we started building changelog integration we also added a text format and it can be grabbed from the command line like so:
# configctl firmware changelog text 22.1
There is no technical reason not to display it other than UX reasons so the question is how to integrate it into the console prompt more or less gracefully. You end up having to pipe it trough "less" most likely and then the question is how many people know how to deal with exiting less without raising a support ticket.
Suggestions welcome. Always happy to review PRs.
Cheers,
Franco
-
Whilst a few of us "me included" failed to understand/read the release notes. Once again I have to say the rapid response from the team was first rate. I wonder how that would have been handled on the other fork :)
-
Well, I would not have thought the day would come when somebody asked for this after all these years. :)
For simplicity the console never did indicate which version you are going to update to during minor iterations and only for major upgrades the confirmation prompt (i.e. "22.1") was added to raise awareness for what you're going to do.
When we started building changelog integration we also added a text format and it can be grabbed from the command line like so:
# configctl firmware changelog text 22.1
There is no technical reason not to display it other than UX reasons so the question is how to integrate it into the console prompt more or less gracefully. You end up having to pipe it trough "less" most likely and then the question is how many people know how to deal with exiting less without raising a support ticket.
Suggestions welcome. Always happy to review PRs.
Cheers,
Franco
Its good to know there is a command I can use to grab the change log. I know its tough to make assumptions, I would think those of us using the console for upgrades know how to use less :-)..
-
Fair enough, I've added https://github.com/opnsense/core/issues/5537 to track it.
Cheers,
Franco
-
For the DHCPv6 issue that users from Orange FR are having. This looks like a kernel problem and I have published a snapshot kernel for broader testing:
# opnsense-update -zkr 22.1-prio
(requires a reboot)
Cheers,
Franco
Being running for several days now without issue so I think we can safley say this fixed IPv6 thanks Franco
-
Happy to hear. We will move the DHCPv6 fix into 22.1.1 :)
Cheers,
Franco