Re: changing ethernet devices, new one stops cold at iptables

Re: changing ethernet devices, new one stops cold at iptables

[Gene Heskett]

On Friday 23 July 2004 07:13, Neil Horman wrote:
>>Gene Heskett wrote:

>> One thing I haven't tried is to reset the MAC address for the
>> nforce2 ethernet to match the D-Links hardware address.  Is it
>> worth a try just to prove the point?
>
>I'd think so.  Its a two minute test to verify that the problem is
>related to the MAC address of nic in the firewall.  You may also
> want to add a LOG target to all the chains in your firewall to
> match on the origional MAC address so you can see what your
> iptables code is doing with the packet.
>
>HTH
>Neil

I'm in the process of trying that Neil, but if thats the case, it 
means I cannot ever re-use that nic in another machine here.  What 
I'd druther do if this test proves positive, is to figure out howto 
get the arp tables updated on the firewall so they reflect the new 
MAC address for this machine.  I've got both drivers as modules 
effective with the next reboot so the testing switching will be much 
easier.

Thanks for the shoulder to cry on.

-- 
Cheers, Gene
There are 4 boxes to be used in defense of liberty. 
Soap, ballot, jury, and ammo.
Please use in that order, starting now.  -Ed Howdershelt, Author
Additions to this message made by Gene Heskett are Copyright 2004, 
Maurice E. Heskett, all rights reserved.

Re: changing ethernet devices, new one stops cold at iptables

[Gene Heskett]

On Friday 23 July 2004 07:13, Neil Horman wrote:
>Gene Heskett wrote:
[...]
>> One thing I haven't tried is to reset the MAC address for the
>> nforce2 ethernet to match the D-Links hardware address.  Is it
>> worth a try just to prove the point?
>
>I'd think so.  Its a two minute test to verify that the problem is
>related to the MAC address of nic in the firewall.  You may also
> want to add a LOG target to all the chains in your firewall to
> match on the origional MAC address so you can see what your
> iptables code is doing with the packet.
>
>HTH
>Neil

ok, rebooted ignored the kudzu stuff about the old 8139too, fired up x 
and used redhat-config-network to deactive both (which now had the 
same MAC address) and rebuilt a new eth0 using the relabeled 
forcedeth driver, moved the cable and restarted the network.  It all 
works.

So, lemme go get the /etc/sysconfig/iptables file and include it, 
because I cannot see anything that makes use of the MAC address in 
any of it.  As you can see from the accounting, lots of data has 
moved.
------------------
# Generated by iptables-save v1.2.7a on Tue May 18 11:20:01 2004
*mangle
:PREROUTING ACCEPT [202871737:120105858881]
:INPUT ACCEPT [139048151:73020278748]
:FORWARD ACCEPT [46936292:35515502787]
:OUTPUT ACCEPT [154434852:126073464036]
:POSTROUTING ACCEPT [188592053:156100678907]
COMMIT
# Completed on Tue May 18 11:20:01 2004
# Generated by iptables-save v1.2.7a on Tue May 18 11:20:01 2004
*nat
:PREROUTING ACCEPT [1095914:117590573]
:POSTROUTING ACCEPT [506424:54549861]
:OUTPUT ACCEPT [506316:54543401]
[458696:27814663] -A POSTROUTING -s 192.168.71.3 -o eth0 -j MASQUERADE
# [] -A POSTROUTING -s 192.168.71.4 -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue May 18 11:20:01 2004
# Generated by iptables-save v1.2.7a on Tue May 18 11:20:01 2004
*filter
:INPUT ACCEPT [764513:261233004]
:FORWARD ACCEPT [899862:777851140]
:OUTPUT ACCEPT [67156239:19633863841]
[152090648:81083207296] -A INPUT -i eth1 -j ACCEPT
[2813341:3132361045] -A INPUT -i eth0 -m state --state 
RELATED,ESTABLISHED -j ACCEPT
[174681:55726580] -A INPUT -i lo -j ACCEPT
[0:0] -I INPUT -p tcp --destination-port 6881:6889 -j ACCEPT
# [0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 6881:6999 
-j ACCEPT
[336:50753] -A INPUT -p tcp -m state --state NEW -m tcp ! --tcp-flags 
SYN,RST,ACK SYN -j LOG --log-prefix "New not
syn: "
[336:50753] -A INPUT -p tcp -m state --state NEW -m tcp ! --tcp-flags 
SYN,RST,ACK SYN -j DROP
[13478612:872497237] -A FORWARD -i eth1 -o eth0 -m state --state 
NEW,RELATED,ESTABLISHED -j ACCEPT
[26626623:33286598582] -A FORWARD -i eth0 -o eth1 -m state --state 
RELATED,ESTABLISHED -j ACCEPT
[87041832:106421017831] -A OUTPUT -o eth1 -j ACCEPT
[521:17036] -A OUTPUT -p icmp -m state --state INVALID -j DROP
[232781:18324718] -A OUTPUT -o eth0 -m state --state 
NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Tue May 18 11:20:01 2004
---------------------

The BitTorrent stuff didn't work :(, but I've not removed it...
Probhably something in the router, a linksys BEFSR41 w/latest flash.

If there is nothing above thats responsible, then it seems to me it 
has to be arp related.  I've just now started studying the manpages 
there, and I'm not too sure what I need to do there in order to 
restore full function to the new MAC address if and when I put it 
back to something nvidia related.  Pointers welcome in any case.

-- 
Cheers, Gene
There are 4 boxes to be used in defense of liberty. 
Soap, ballot, jury, and ammo.
Please use in that order, starting now.  -Ed Howdershelt, Author
Additions to this message made by Gene Heskett are Copyright 2004, 
Maurice E. Heskett, all rights reserved.

Re: changing ethernet devices, new one stops cold at iptables

[Gene Heskett]

On Sunday 25 July 2004 05:50, Henrik Nordstrom wrote:
>On Thu, 22 Jul 2004, Gene Heskett wrote:
>> I can ping the firewall, and I can ssh into it, so that part of
>> the network is fine, I just cannot get past iptables in the
>> firewall when eth0 is the nforce hardware, which has a different
>> MAC address.
>
>Have you verified that the routing got correctly set up on the new
> box?
>
>   ip ro ls
>
>The usual cause to the symptoms you describe is that the default
> route has gone missing or is invalid.

The routing was good, showing the fireall as the default gateway 
address.

In this case, the fix was to reboot the firewall so that its arp 
tables got refreshed to match the new MAC address of the onboard 
nforce (forcedeth) nic.  Once that was done, everything was peachy.

Thanks, I appreciate the reply, Henrik.

-- 
Cheers, Gene
There are 4 boxes to be used in defense of liberty. 
Soap, ballot, jury, and ammo.
Please use in that order, starting now.  -Ed Howdershelt, Author
Additions to this message made by Gene Heskett are Copyright 2004, 
Maurice E. Heskett, all rights reserved.

Re: changing ethernet devices, new one stops cold at iptables

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

No need to reboot it.  Simply flush the neighbor cache.

Scott root # ip neigh flush help
Usage: ip neigh { add | del | change | replace } { ADDR [ lladdr LLADDR ]
          [ nud { permanent | noarp | stale | reachable } ]
          | proxy ADDR } [ dev DEV ]
       ip neigh {show|flush} [ to PREFIX ] [ dev DEV ] [ nud STATE ]

David

Gene Heskett wrote:

>On Sunday 25 July 2004 05:50, Henrik Nordstrom wrote:
>  
>
>>On Thu, 22 Jul 2004, Gene Heskett wrote:
>>    
>>
>>>I can ping the firewall, and I can ssh into it, so that part of
>>>the network is fine, I just cannot get past iptables in the
>>>firewall when eth0 is the nforce hardware, which has a different
>>>MAC address.
>>>      
>>>
>>Have you verified that the routing got correctly set up on the new
>>box?
>>
>>  ip ro ls
>>
>>The usual cause to the symptoms you describe is that the default
>>route has gone missing or is invalid.
>>    
>>
>
>The routing was good, showing the fireall as the default gateway 
>address.
>
>In this case, the fix was to reboot the firewall so that its arp 
>tables got refreshed to match the new MAC address of the onboard 
>nforce (forcedeth) nic.  Once that was done, everything was peachy.
>
>Thanks, I appreciate the reply, Henrik.
>
>  
>

[-- Attachment #2: david+challenge-response.vcf --]
[-- Type: text/x-vcard, Size: 183 bytes --]

begin:vcard
fn:David Ford
n:Ford;David
email;internet:david@blue-labs.org
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: changing ethernet devices, new one stops cold at iptables

[Gene Heskett]

On Sunday 25 July 2004 17:23, David Ford wrote:
>No need to reboot it.  Simply flush the neighbor cache.
>
>Scott root # ip neigh flush help
>Usage: ip neigh { add | del | change | replace } { ADDR [ lladdr
> LLADDR ] [ nud { permanent | noarp | stale | reachable } ]
>
>          | proxy ADDR } [ dev DEV ]
>
>       ip neigh {show|flush} [ to PREFIX ] [ dev DEV ] [ nud STATE ]
>
>David

Is my manpages too old?  I studied it for arp at least half an hour 
without seeing any way out of the dilemma short of a reboot, so I 
did.  And I just checked, theres no linkage from arp to anything 
called 'ip'.  Wrecked a 78 day uptime :(

Yes, I learned something from your message, thank you very much, but 
why is it so deeply buried?

Humm, is there not an option that will a: flush, and then b: refresh 
itself just as if its been rebooted?  The 'replace' appears to 
require intimate knowledge of a 48 bit MAC address etc I'd assume.

 
>Gene Heskett wrote:
>>On Sunday 25 July 2004 05:50, Henrik Nordstrom wrote:
>>>On Thu, 22 Jul 2004, Gene Heskett wrote:
>>>>I can ping the firewall, and I can ssh into it, so that part of
>>>>the network is fine, I just cannot get past iptables in the
>>>>firewall when eth0 is the nforce hardware, which has a different
>>>>MAC address.
>>>
>>>Have you verified that the routing got correctly set up on the new
>>>box?
>>>
>>>  ip ro ls
>>>
>>>The usual cause to the symptoms you describe is that the default
>>>route has gone missing or is invalid.
>>
>>The routing was good, showing the fireall as the default gateway
>>address.
>>
>>In this case, the fix was to reboot the firewall so that its arp
>>tables got refreshed to match the new MAC address of the onboard
>>nforce (forcedeth) nic.  Once that was done, everything was peachy.
>>
>>Thanks, I appreciate the reply, Henrik.

-- 
Cheers, Gene
There are 4 boxes to be used in defense of liberty. 
Soap, ballot, jury, and ammo.
Please use in that order, starting now.  -Ed Howdershelt, Author
Additions to this message made by Gene Heskett are Copyright 2004, 
Maurice E. Heskett, all rights reserved.