[CentOS] C7: NM and changing MAC addresses
i need a way to stop anything from changing my external MAC address, as my ISP is extremely sensitive to additional MAC addresses appearing on my external NIC. i have done sudo nmcli conn mod eno1 802-3-ethernet.cloned-mac-address permanent and it's improved matters, but here's an example of it going wrong even so, from "tcpdump -n -n -e -i eno1 src 185.219.108.121" (which is my ipv4): 10:23:58.210653 ac:1f:6b:6c:5a:6e > bc:30:5b:f7:3e:c8, ethertype IPv4 (0x0800), length 114: 185.219.108.121.53002 > 198.252.206.25.443: Flags [P.], seq 2018:2066, ack 5333, win 501, options [nop,nop,TS val 4035938817 ecr 1709670339], length 48 10:23:58.405154 ac:1f:6b:6c:5a:6e > bc:30:5b:f7:3e:c8, ethertype IPv4 (0x0800), length 66: 185.219.108.121.44534 > 216.58.212.234.443: Flags [.], ack 21641, win 501, options [nop,nop,TS val 805137946 ecr 1062125308], length 0 10:23:58.447030 ac:1f:6b:6c:58:2d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.219.108.1 tell 185.219.108.121, length 46 10:23:58.447466 ac:1f:6b:6c:58:2d > bc:30:5b:f7:3e:c8, ethertype IPv4 (0x0800), length 342: 185.219.108.121.68 > 185.219.108.1.67: BOOTP/DHCP, Request from ac:1f:6b:6c:58:2d, length 300 10:23:58.629131 ac:1f:6b:6c:5a:6e > bc:30:5b:f7:3e:c8, ethertype IPv4 (0x0800), length 98: 185.219.108.121 > 8.8.8.8: ICMP echo request, id 105, seq 67, length 64 note the first two frames coming from ac:1f:6b:6c:5a:6e, the real MAC address, which has been happily all over the headers of the previous several thousand frames, but then two frames from ac:1f:6b:6c:58:2d, which *utterly* screw up my connection to my ISP. the old MAC address continues to be on some of the outgoing traffic. i have some grounds for thinking that the first or second frame with the "bad" mac address is always a BOOTP/DHCP frame, so i'm open to the idea that this is dhclient being "helpful", rather than NM. does anyone have any idea which daemon or service is responsible for this MAC-rebadging, and/or how i might stop it? -- Tom Yates - https://www.teaparty.net ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Postfix and virtual mail boxes.[SOLVED - kinda]
On 11/10/21 2:06 pm, Rob Kampen wrote: OK - just to let you know the munge I used. example.com is an alias domain for example.org which is the actual domain with Maildir space on the server. rob@ is alias for rkampen@ thus the only real address is rkam...@example.org That's not what I meant by munge, but it helps. Anyhow, what you showed me is what I need to see. now the results This is all good, except... [root@mx rkampen]# postmap -q @example.com mysql:/etc/postfix/mysql-virtual_forwardings.cf @example.org This is a bad idea. It's not the cause of your problem (as you discovered below) but it will lead you to become a backscatter source. I'll explain. Postfix checks virtual_alias_maps entries twice, once in smtpd and once in cleanup (actually trivial_rewrite, which is called from cleanup). At the smtpd stage it simply checks to make sure that there is a virtual_alias_map entry for the recipient address, but it doesn't care where that entry points, then (after other checks) postfix accepts and queues the message. The message is then passed to cleanup, which, as once of its functions, calls trivial_rewrite which, once again, checks virtual_alias_maps and in turn rewrites the recipient to the target email address. (It then loops and does this until there are no more rewrites to be done). Then delivery is attempted to the target address. So in your case, what happens when the original recipient is "nonexist...@example.com"? Well Postfix first checks virtual_alias_maps for entries of "nonexist...@example.com", "nonexistent" and "@example.com", it finds a match for the last of these and so the message passes the checks in smtpd and the message is accepted for delivery and queued. Then the message is passed to cleanup which checks with trivial_rewrite and trivial_rewrite checks virtual_alias_maps (again) and after finding the "@example.com" entry it rewrites the recipient to "nonexist...@example.org". Then Postfix attempts to deliver the message to nonexist...@example.org, but since there's no such recipient and since postfix has already accepted the message for delivery it generates a bounce message which it sends to the envelope sender. Thus you have a situation where messages can be sent to invalid recipients and your system will bounce them, and as such you become a source of backscatter. You can confirm this by attempting to send a message to nonexist...@example.com and another one to nonexist...@example.org. The example.com one will generate a bounce from Postfix while the example.org one will reject the message instead (you'll be able to see the difference in your Postfix logs). The solution here is to not use an @example.com entry in virtual_alias_maps, but instead to have a separate entry for each valid recipient in example.com. Since you're using mysql it is possible to craft a mysql query that can check the valid example.org recipients and only return example.com matches for those recipients, I'll leave that as an exorsize for you, but if you have problems with it I'll be happy to help. Well that may have done it! Now I get a correctly sent email with the alias substitutions done. Funny how that line seems to cause no error on my two original MX - looks like I better check them out a little more too. That's great. So basically what you've done by removing that entry is to bypass the policyd-spf check from Postfix. What that means is that the problem is in policyd-spf and this is further confirmed by the following log entry: Oct 11 13:53:10 mx policyd-spf[10723]: ERROR: Unknown name "TestOnly" in file "/etc/python-policyd-spf/policyd-spf.conf" Unfortunately I am not a policyd-spf expert by any stretch, so at this stage I'll direct you to their community support for further help (unless someone else here wants to chime in and help). What I can say is that if you fix your policyd-spf issue then it is likely that you can add that entry back into the Postfix configuration and it will work. Thanks Peter, your help has been invaluable and MUCH appreciated! You're quite welcome. Peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C7: NM and changing MAC addresses
El 11/10/21 a las 11:55, Tom Yates escribió: i need a way to stop anything from changing my external MAC address, as my ISP is extremely sensitive to additional MAC addresses appearing on my external NIC. i have done sudo nmcli conn mod eno1 802-3-ethernet.cloned-mac-address permanent and it's improved matters, but here's an example of it going wrong even so, from "tcpdump -n -n -e -i eno1 src 185.219.108.121" (which is my ipv4): 10:23:58.210653 ac:1f:6b:6c:5a:6e > bc:30:5b:f7:3e:c8, ethertype IPv4 (0x0800), length 114: 185.219.108.121.53002 > 198.252.206.25.443: Flags [P.], seq 2018:2066, ack 5333, win 501, options [nop,nop,TS val 4035938817 ecr 1709670339], length 48 10:23:58.405154 ac:1f:6b:6c:5a:6e > bc:30:5b:f7:3e:c8, ethertype IPv4 (0x0800), length 66: 185.219.108.121.44534 > 216.58.212.234.443: Flags [.], ack 21641, win 501, options [nop,nop,TS val 805137946 ecr 1062125308], length 0 10:23:58.447030 ac:1f:6b:6c:58:2d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.219.108.1 tell 185.219.108.121, length 46 10:23:58.447466 ac:1f:6b:6c:58:2d > bc:30:5b:f7:3e:c8, ethertype IPv4 (0x0800), length 342: 185.219.108.121.68 > 185.219.108.1.67: BOOTP/DHCP, Request from ac:1f:6b:6c:58:2d, length 300 10:23:58.629131 ac:1f:6b:6c:5a:6e > bc:30:5b:f7:3e:c8, ethertype IPv4 (0x0800), length 98: 185.219.108.121 > 8.8.8.8: ICMP echo request, id 105, seq 67, length 64 note the first two frames coming from ac:1f:6b:6c:5a:6e, the real MAC address, which has been happily all over the headers of the previous several thousand frames, but then two frames from ac:1f:6b:6c:58:2d, which *utterly* screw up my connection to my ISP. the old MAC address continues to be on some of the outgoing traffic. i have some grounds for thinking that the first or second frame with the "bad" mac address is always a BOOTP/DHCP frame, so i'm open to the idea that this is dhclient being "helpful", rather than NM. does anyone have any idea which daemon or service is responsible for this MAC-rebadging, and/or how i might stop it? Hello Perhaps the solution is this: https://access.redhat.com/solutions/70215HWADDR= Never see in CentOS but yes in Proxmox (bridge). Adding HWADDR= was a solution for me. But note this article asks you to change HWADDR= to MACADDR= Hope helps ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C7: NM and changing MAC addresses
El 11/10/21 a las 13:00, Tom Yates escribió: On Mon, 11 Oct 2021, José María Terry Jiménez wrote: Hello Perhaps the solution is this: https://access.redhat.com/solutions/70215HWADDR= thanks, but either that link is broken, or the site requires a login, as i can't see anything and get redirected to a general search page. could i trouble you to check the link? Uh oh! Some copypaste at the end Is this one https://access.redhat.com/solutions/70215 Checked I'm not logged into RH ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C7: NM and changing MAC addresses
On Mon, 11 Oct 2021, José María Terry Jiménez wrote: El 11/10/21 a las 13:00, Tom Yates escribió: On Mon, 11 Oct 2021, José María Terry Jiménez wrote: Hello Perhaps the solution is this: https://access.redhat.com/solutions/70215HWADDR= thanks, but either that link is broken, or the site requires a login, as i can't see anything and get redirected to a general search page. could i trouble you to check the link? Uh oh! Some copypaste at the end Is this one https://access.redhat.com/solutions/70215 thank you very much for the suggestion! sadly, this has not worked. -- Tom Yates - https://www.teaparty.net ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C7: NM and changing MAC addresses
Hi, > On Mon, 11 Oct 2021, José María Terry Jiménez wrote: > >> El 11/10/21 a las 13:00, Tom Yates escribió: >>> On Mon, 11 Oct 2021, José María Terry Jiménez wrote: >>> Hello Perhaps the solution is this: https://access.redhat.com/solutions/70215HWADDR= >>> >>> thanks, but either that link is broken, or the site requires a login, >>> as i >>> can't see anything and get redirected to a general search page. could >>> i >>> trouble you to check the link? >>> >>> >> Uh oh! Some copypaste at the end >> >> Is this one >> >> https://access.redhat.com/solutions/70215 > > thank you very much for the suggestion! sadly, this has not worked. > Are you even sure it's NetworkManager messing with your MAC addresses? I have no idea why NM should ever mess with MAC addresses on a server and I don't expect NM is doing so. I have another idea: Seems this is on a SuperMicro server, can it be that the box in question has a shared lights out management, sharing the management ethernet port with the first LAN port? If so, can it be that the management port is not configured properly and does try to DHCP an IPv4 address? If you don't need the management stuff then you may try to simply disable it to get rid of the mess. Regards, Simon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C7: NM and changing MAC addresses
> On 11.10.2021, at 17:22, Simon Matter wrote: > > Hi, > >> On Mon, 11 Oct 2021, José María Terry Jiménez wrote: >> >>> El 11/10/21 a las 13:00, Tom Yates escribió: On Mon, 11 Oct 2021, José María Terry Jiménez wrote: > Hello > > Perhaps the solution is this: > > https://access.redhat.com/solutions/70215HWADDR= thanks, but either that link is broken, or the site requires a login, as i can't see anything and get redirected to a general search page. could i trouble you to check the link? >>> Uh oh! Some copypaste at the end >>> >>> Is this one >>> >>> https://access.redhat.com/solutions/70215 >> >> thank you very much for the suggestion! sadly, this has not worked. >> > > Are you even sure it's NetworkManager messing with your MAC addresses? I > have no idea why NM should ever mess with MAC addresses on a server and I > don't expect NM is doing so. > > I have another idea: Seems this is on a SuperMicro server, can it be that > the box in question has a shared lights out management, sharing the > management ethernet port with the first LAN port? If so, can it be that > the management port is not configured properly and does try to DHCP an > IPv4 address? If you don't need the management stuff then you may try to > simply disable it to get rid of the mess. Yeah, there is a default setting in the Firmware of “failover” which means “use dedicated IPMI port if connected otherwise use shared LAN port” This is under IPMI -> BMC Network Configuration see also https://serverfault.com/questions/361940/configuring-supermicro-ipmi-to-use-one-of-the-lan-interfaces-instead-of-the-ipmi But, is this kind of traffic supposed to be visible to the linux kernel? (or was the tcpdump made on another machine?) Best Regards, Markus ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
