Windows en linux machine zien elkaar niet.

[VROEM!]

Ik heb hier een windows en een linux bak die elkaar niet willen pingen.

Ze hebben de volgende instellingen:

code:

[b]LINUX[/b]
eth1:
address = 10.0.0.3
netmask = 255.0.0.0 (zelfde als LO)
broadcast = 10.0.0.255
network = 10.0.0.0

[b]WINDOWS 98SE[/b]
adres: 10.0.0.7
netmask 255.0.0.0
gateway 10.0.0.3

ipmasquerading is aan en in mijn ipchains firewall laat ik ping verkeer van alle kanten toe.

[VROEM!]

En nog wat: ik heb de ipchains firewall steeds ingesteld dmv webmin. Sindsdien krijg ik bij elke config wijziging de volgende melding:

code:

/etc/init.d: ipcalc: command not found
Using /lib/modules/2.2.19/ipv4/ip_masq_ftp.o

[_Squatt_]

Ik ben geen netwerk expert, maar ik dacht dat als je netmask 255.0.0.0 is, dat je broadcast dan x.255.255.255 was...

Dat weet ik echter niet zeker, maar zo heb ik 't hier wel.
(Netmask = 255.255.0.0, Broadcast = x.x.255.255)

[VROEM!]

Ik heb het volgende gewijzigd:

windows-->
192.168.1.7, netmask 255.255.255.0, gateway 192.168.1.3

linux-->
addres 192.168.1.3
netmask 255.255.255.0
broadcast 192.168.1.255
network 192.168.1.0

Nog steeds geen resultaat

[Verwijderd]

probeer het eerst 'ns zonder gateways

[Valium]

En post een route en een iptables list van je linux-bak. Dan kun je het snel genoeg zien.
Ow ja, en ifconfig

Werken de kaartjes eigenlijk wel? En zitten de stekkers er wel in? (Was gisteravond een probleem bij een niet nader te noemen tweaker....)

[Verwijderd]

Op vrijdag 05 april 2002 16:03 schreef Valium het volgende:
Werken de kaartjes eigenlijk wel? En zitten de stekkers er wel in? (Was gisteravond een probleem bij een niet nader te noemen tweaker....)

die gozer is nep Tweaker

[Verwijderd]

probeer het eens zonder firewall---just to make sure

Heb je de goede kabel (crossed/normaal)?

[VROEM!]

Alles heeft met windows en dezelfde kabels gewerkt. De kabels zijn allemaal gewone kabels (niet gecrossed) en zitten aan een hub. Lampjes op de hub branden, dus dat zal wel ok zijn dacht ik zo.

na met ipchains -P accept input/output en forward alles open te hebben gezet is het probleem gebleven.

route

code:

Metric, use, ref alles 0. Verder:
Destination  Gateway  Flags  Iface
192.168.1.0  *    U eth1
145.94.192.0 *    U eth0
default *     UG     eth0

Eth0 zit aan internet en werkt. Ik kan er ook mee downloaden. Wat betekenen de flags eigenlijk?

ifconfig Volgorde kan lichtelijk verbouwd zijn...

code:

eth0 (krijgt alles van dhcp en ik heb via die ook kunnen webminnen)
address 145.94.196.105 broadcast 145.94.255.255 netmask 255.255.192.0
UP BROADCAST RUNNING metric: 1

eth1 (statisch)
address 192.168.1.3 broadcast 192.168.1.255 netmask 255.255.255.0
UP RUNNING BROADCAST MULTICAST
metric: 1

lo 
IP 127.0.0.1, mask 255.0.0.0 UP LOOPBACK RUNNING
metric: 1

Het gekke is dat als ik die machine ping op de pingende machine wel een error krijg, maar op de linux bak loopt het aantal rx packets keurig op zonder errors.



IP tables wil ik wel posten, maar dat zit toch pas in de 2.4 kernels? Mijn kernel is 2.2.19

Eth1 zit aan het interne netwerk

[edit: eth0 was eth1]

[VROEM!]

*ademt diep in*......WWWHHHEEEEEEELLLLLLLLLLLLLLLLLPPPPP!!!!

[Verwijderd]

Dus als ik het goed begrijp werkt het wel als je met ipchains alles accepteert en niet als je jouw default ipchains script runt.

Als dat zo is dan moet je in je scriptje het een en ander wijzigen dunkt me.....

*********
ooopssss.....verkeerd gelezen...sorry.......
*********

[Verwijderd]

Heb je misschien een firewall op je windows bak?

[VROEM!]

Nee, het is een zo kaal als mogelijke windows 98 installatie op een 486DX (30mb vrij op een 240 mb harddisk )
Mijn XP bak heeft de firewall uit.

Als ik beide windows bakken via DHCP configureer kan ik eth0 wel pingen. (eth0 zit via DHCP aan BybyXL van de TU delft) Die krijgen dan het zelfde subnet etc als eth0.

[VROEM!]

Oke, security level staat nu op low. Webmin heeft de volgende dingen ingesteld:

code:

Protocol   Allowed Directions 

--------------------------------------------------------------------------------
 
DHCP   Inside -> FW 
DNS   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside, FW -> Inside, FW -> Outside 
FTP-Active   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside, FW -> Inside, FW -> Outside 
FTP-Passive   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside 
HTTP   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside, FW -> Inside, FW -> Outside 
HTTPS   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside, FW -> Inside, FW -> Outside 
IMAP   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside 
IRC   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside 
LDAP   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside 
NFS   Inside -> FW, Outside -> FW 
NTP   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside, FW -> Inside, FW -> Outside 
NetBIOS   Inside -> FW, Outside -> FW 
POP3   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside 
Ping   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside, FW -> Inside, FW -> Outside 
SMTP   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside, FW -> Inside, FW -> Outside 
SSH   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside, FW -> Inside, FW -> Outside 
Webmin   Inside -> FW, Inside -> Outside, Outside -> FW, Outside -> Inside, FW -> Inside, FW -> Outside

ipmasquerading is enabled en nog steeds nada niks. Packets worden wel ontvangen (in ifconfig loopt na 4 packets pingen het aantal Rx packets met 4 op) maar er komt niks terug. Errors krijg ik op de linux machine niet en op de windows machine krijg ik time outs.

[VROEM!]

Firewall uit en masquerading uit: zelfde verhaal.

Met dmesg zie ik nu trouwens allerlei meldingen van packet deny etc etc....

Let op: Die meldingen krijg ik alleen als ik van de linux bak de windows bak probeer te pingen!

code:

Packet log: input DENY eth1 PROTO=17 145.94.196.105:138 145.94.255.255:138 L = 241 s=0x00 I=93 F=0x000 T = 64

Hierbij loopt bij elke nieuwe melding het getal I= eentje op.

[Verwijderd]

Ik zou eens (overnieuw) beginnen...

probeer eerst eens of je netwerk werkt zonder welke ipchains configuratie dan ook.....pingen moet kunnen als je netwerk adressen kloppen....Pas als je pc-tjes elkaar zien ga je je ipchains script opbouwen.
Je weet nu namelijk niet zeker of je iets in je ipchains fout hebt staan of dat er iets anders aan de hand is

[VROEM!]

Ik heb nu met webmin de ipchains firewall compleet uitgezet.
Rebootje erover....

Nog steeds hetzelfde (ook die deny melding)

Ik heb nu IP forwarding uit, ipmasq eruit geknikkerd en er wordt nu gereboot...

Noch immer niks. De INPUT deny meldingen zijn nu wel weg.

[VROEM!]

In wat voor bestanden kan ik controleren of ipchains etc _echt_helemaal uit staat? Routing is nog steeds aan lijkt het.

Route geeft het volgende

code:

Metric, use, ref alles 0. Verder:
Destination  Gateway  Flags  Iface
192.168.1.0  *    U eth1
145.94.192.0 *    U eth0
default *     UG     eth0

Bij route -n is de laatste regel (default) de volgende:

code:

destination gateway    genmask   Flags/Metric/ref/use/Iface
0.0.0.0     145.94.192.1    0.0.0.0   UG   0   0   0   eth0

[deadinspace]

ipchains -L

[VROEM!]

Ook met ipchains -L alleen maar packetloss.

[VROEM!]

Ik heb er ook maar eens een andere netwerkkaart in gedaan en een andere kabel aangehangen, maar nog steeds hetzelfde resultaat.

De netwerkkaart is nagenoeg identiek aan degene die erin zat en ze gebruiken dezelfde modules en io adressen, dus dat mag geen verschil maken.

[Verwijderd]

Routing wordt niet met ipchains geregeld en die staat ook goed...

Ipchains zal waarschijnlijjk ergens in een scriptje staan in /etc/init.d/blablabla...(afhankelijk van je distro)

--------
een rigoreuze maatregel (tijdelijk) is ff kijken wwar jouw ipchains zich bevind met 'whereis ipchains' en deze vervolgens ff naar je homedir verplaatsen -- tijdens het rebooten of uitvoeren krijg je dan wel een aantal errors omdat hij ipchains daar niet kan vinden maar die zijn weer over zodra je dit weer terug zet

[Buffy]

Op vrijdag 05 april 2002 22:48 schreef VROEM! het volgende:

code:

Packet log: input DENY eth1 PROTO=17 145.94.196.105:138 145.94.255.255:138 L = 241 s=0x00 I=93 F=0x000 T = 64

Wel een vreemde melding.
Betreft een NETBIOS datagram pakketje dat binnen komt op de interface van het interne netwerk (eth1) en als source adress 145.94.196.105 heeft.

Ten eerste hoort dat niet via eth1 binnen te komen maar eth0 (je externe network) en ten tweede stond in een van je eerdere post dat 145.94.196.105 het IP adres van je eth0 interface is op je linux bak.

Heb je de twee interfaces niet verkeert om geconfigureerd?

(NETBIOS port 138 heeft overigens niks met ping te maken :-)

[VROEM!]

WHHHOOOHOOOO! Hij doet het!

owkey, hoe krijg ik nu voor elkaar dat ie ook werkt met ipchains erop?

[deadinspace]

ipchains -L laat de huidige rules in je (ipchains-) firewall zien, en met ipchains -F kun je alle rules wissen.

Die meldingen van deny in je logs wijzen er in ieder geval best wel op dat de pings en de replies daarop door je firewall geblockt worden.

[Verwijderd]

Ik ben erg nieuwsgierig...maar wat was nu het probleem...wat heb je nu gedaan??????


Als het probleem in je ipchains zit zal je eens goed naar je script moeten kijken.....
Als je geen zin hebt om er zelf een te bouwen dan is http://www.linux-firewall-tools.com een hele leuke site om online een firewall te bouwen...

[VROEM!]

Ik had die IPCHAINS executables uit /sbin verplaatst naar /install en nu doet ie het. Maar zodra ik ze terug plaats krijg ik natuurlijk mijn probleem weer terug. Ik heb ipchains nodig om een firewall te bouwen dus die moet er weer op.

[Verwijderd]

Hmmm...dan zit het probleem dus toch in je ipchains configuratie.

Je kan 2 dingen doen...of een nieuwe bouwen en ff de manpage goed doorlezen (kijk eens naar die site die ik noemde)

of je post je huidige script en hoopt dat iemand de fout vindt.....

[VROEM!]

Hey, ipmasq is terug geplaatst (had ik ook verwijderd) en nu doet ie het weer niet

Wacht effe...ip forwarding had ik gelijk ook aan gezet (was net uit). Nu weer uit, zonder ipmasq....weer niks

Oke, ipchains executables zijn verplaatst naar /install, ipmasq is niet geinstalleerd

[VROEM!]

ipchains is voor alle duidelijkheid sinds het verplaatsen van de executables NIET terug gezet. Elk ipchains commando geeft dus een error.

ipcalc is bij de weg ook niet geinstalleerd.

[VROEM!]

Ik doe nog maar effe een re-install op een andere machine met 1 netwerkkaart. Eens zien wat die dan doet.

Blijf nog maar wel even komen met de tips bij de weg...

[VROEM!]

*schop* iemand?

[VROEM!]

Oke, ik heb nu de driver vervangen, de kaart vervangen en nog steeds doet ie het niet. De kaart die eerst in de linux machine zat werkt nu vlekkeloos in een windows machine en een identieke kaart zit nu in een andere linux machine ook vlekkeloos te werken. Kabels vervangen helpt niet...zucht.

Iemand?

[Buffy]

Als je denkt dat het een firewall probleem is probeer dan eens het volgende:

ipchains-save > /tmp/ipchains.rules

Edit dan /tmp/ipchains.rules als volgt:

zet achter elke -A ....... -j DENY|REJECT|MASQ|ACCEPT regel de optie '-l'
als die er nog niet staat. Let op, als de regel eindigd met de '-y' optie dan
moet de '-l' optie ervoor.

En aan het einde van de '-A output ....' regels moet de volgende extra regel

-A output -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -l

evenals aan het einde van de '-A input ....' regels

-A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -l

en aan het einde van de '-A forward .....' regels

-A forward -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -l


Overigens de acties ('-j DENY' hierboven) van de extra regels moeten overeen komen met de default policy van de input, output en forward chains zoals bovenaan de /tmp/ipchains-rules staat vermeld.


Hierna de aangepast /tmp/ipchains.rules laden:

ipchains-restore -f < /tmp/ipchains.rules


En als het goed is kan je dan in de kernel logfile (check /etc/syslog.conf waar de kern.* meldingen heen gaan) of met dmesg zien wat er moet de ping pakketjes gebeurd (ICMP is PROTO=1).

[VROEM!]

Goed, gisteravond even een clean install gedaan. Nu heb ik de kaarnummers even omgedraaid (intern = eth0, extern = eth1)

ik heb met ipchains -L even alles uit gezet. In /var/log/messages komt het volgende te staan als ik de computer probeer te pingen:

mc: /dev/gpmctl: Connection refused.

Ik bekijk het bestand vanuit de midnight commander. Elke keer als ik de computer probeer te pingen komt er een regeltje met dezelfde melding bij. Als ik het bestand meerdere keren achter elkaar open zonder pingen komt er geen regel bij.

Vraagje nog: kan dit geklooi misschien te maken hebben met dat beide kaarten aan dezelfde hub hangen? Met een andere compu was dit nooit een probleem, maar ik wordt nu wel nieuwsgierig.

Ipchains script heb ik weer even gebouwd via webmin en ik ga hem nu verbouwen.

[TrailBlazer]

ok dit is mijn werkende scriptje

code:

#!/bin/sh
echo "Firewalll version 0.1 by eelco"
echo 1 > /proc/sys/net/ipv4/ip_forward
#Flush all
echo "Flushing"
/sbin/ipchains -P input DENY
/sbin/ipchains -P output DENY
/sbin/ipchains -P forward DENY 
/sbin/ipchains -F input
/sbin/ipchains -F output
/sbin/ipchains -F forward
#Modem Traffic
/sbin/ipchains -A input -i eth2 -s 10.0.0.138 -d 10.0.0.100 -j ACCEPT
/sbin/ipchains -A output -i eth2 -d 10.0.0.138 -s 10.0.0.100 -j ACCEPT


#Local Traffic
/sbin/ipchains -A input -i lo -j ACCEPT
/sbin/ipchains -A output -i lo -j ACCEPT
/sbin/ipchains -A input -i eth0 -s 192.168.0.0/24 -j ACCEPT
/sbin/ipchains -A output -i eth0 -d 192.168.0.0/24 -j ACCEPT
/sbin/ipchains -A input -i eth1 -s 192.168.1.0/24 -j ACCEPT
/sbin/ipchains -A output -i eth1 -d 192.168.1.0/24 -j ACCEPT
/sbin/ipchains -A forward -i eth1 -d 192.168.1.0/24 -s 192.168.0.0/24 -j ACCEPT 
/sbin/ipchains -A forward -i eth0 -d 192.168.0.0/24 -s 192.168.1.0/24 -j ACCEPT 

#Internet Traffic
/sbin/ipchains -A input -p icmp -i eth2 -s 0.0.0.0/0 -d 10.0.0.100 -j ACCEPT
/sbin/ipchains -A input -p TCP -i eth2 -s 0.0.0.0/0 -d 10.0.0.100 1024: -j ACCEPT
/sbin/ipchains -A input -p UDP -i eth2 -s 0.0.0.0/0 -d 10.0.0.100 1024: -j ACCEPT
echo "Specifying friends"
#Masquerading

echo "Masqueradig"
/sbin/ipchains -A forward -i eth2 -s 192.168.0.0/24 -j MASQ
/sbin/ipchains -A forward -i eth2 -s 192.168.1.0/24 -j MASQ
/sbin/ipchains -A forward -i eth2 -s 192.168.0.0/24 -d 10.0.0.138 -j MASQ -l
/sbin/ipchains -A forward -i eth2 -s 192.168.1.0/24 -d 10.0.0.138 -j MASQ -l

Ik heb 3 netwerkkaarten in deze bak zitten
eth2 is mijn kaart naar adsl modem
eth1 is mijn kaart naar mijn server
eth0 is de kaart naar werkstation

naja mocht je nog vragen hebben ik hoor het wel

[Buffy]

Op zondag 07 april 2002 15:01 schreef VROEM! het volgende:

mc: /dev/gpmctl: Connection refused.

Dit lijkt me meer een melding van midnight commander die de mouse-control device probeert te openen wat blijkbaar maar niet mag.

Vraagje nog: kan dit geklooi misschien te maken hebben met dat beide kaarten aan dezelfde hub hangen? Met een andere compu was dit nooit een probleem, maar ik wordt nu wel nieuwsgierig.

Twee netwerken op 1 hub, hhmmm.
Klinkt gewaagd maar zie niet waarom niet. Je kan geloof ik zelf twee netwerken op 1 netwerkkaart hebben.

[VROEM!]

Op zondag 07 april 2002 15:11 schreef TrailBlazer het volgende:
ok dit is mijn werkende scriptje

code:

#!/bin/sh
echo "Firewalll version 0.1 by eelco"
echo 1 > /proc/sys/net/ipv4/ip_forward
#Flush all
echo "Flushing"
/sbin/ipchains -P input DENY
/sbin/ipchains -P output DENY
/sbin/ipchains -P forward DENY 
/sbin/ipchains -F input
/sbin/ipchains -F output
/sbin/ipchains -F forward
#Modem Traffic
/sbin/ipchains -A input -i eth2 -s 10.0.0.138 -d 10.0.0.100 -j ACCEPT
/sbin/ipchains -A output -i eth2 -d 10.0.0.138 -s 10.0.0.100 -j ACCEPT


#Local Traffic
/sbin/ipchains -A input -i lo -j ACCEPT
/sbin/ipchains -A output -i lo -j ACCEPT
/sbin/ipchains -A input -i eth0 -s 192.168.0.0/24 -j ACCEPT
/sbin/ipchains -A output -i eth0 -d 192.168.0.0/24 -j ACCEPT
/sbin/ipchains -A input -i eth1 -s 192.168.1.0/24 -j ACCEPT
/sbin/ipchains -A output -i eth1 -d 192.168.1.0/24 -j ACCEPT
/sbin/ipchains -A forward -i eth1 -d 192.168.1.0/24 -s 192.168.0.0/24 -j ACCEPT 
/sbin/ipchains -A forward -i eth0 -d 192.168.0.0/24 -s 192.168.1.0/24 -j ACCEPT 

#Internet Traffic
/sbin/ipchains -A input -p icmp -i eth2 -s 0.0.0.0/0 -d 10.0.0.100 -j ACCEPT
/sbin/ipchains -A input -p TCP -i eth2 -s 0.0.0.0/0 -d 10.0.0.100 1024: -j ACCEPT
/sbin/ipchains -A input -p UDP -i eth2 -s 0.0.0.0/0 -d 10.0.0.100 1024: -j ACCEPT
echo "Specifying friends"
#Masquerading

echo "Masqueradig"
/sbin/ipchains -A forward -i eth2 -s 192.168.0.0/24 -j MASQ
/sbin/ipchains -A forward -i eth2 -s 192.168.1.0/24 -j MASQ
/sbin/ipchains -A forward -i eth2 -s 192.168.0.0/24 -d 10.0.0.138 -j MASQ -l
/sbin/ipchains -A forward -i eth2 -s 192.168.1.0/24 -d 10.0.0.138 -j MASQ -l

Ik heb 3 netwerkkaarten in deze bak zitten
eth2 is mijn kaart naar adsl modem
eth1 is mijn kaart naar mijn server
eth0 is de kaart naar werkstation

naja mocht je nog vragen hebben ik hoor het wel

Ik heb wat vragen over de IP adressen:
Welke is van welke kaart en welke zijn van andere computers dan je server? Alles dat eindigt op .0/24 is als het goed is van je interne netwerk met een netmask van 255.255.255.0

Verder: Waarom heb je bovenaan de regels met -F input etc na de regels met -P input etc DENY staan? Met -F haal je toch vorige regels weg, maw je maakt die deny regels toch ongedaan?

Als laatste: die adressen met 0.0.0.0, is dat wat je invult als je kaart zijn instellingen met DHCP op moet halen?

Als laatste+1 : Ik blokkeer toch geen verkeer van intern met ssh via dit script? Dat moet voorlopig nog wel effe gehandhaafd blijven.

[odysseus]

Op zondag 07 april 2002 17:42 schreef VROEM! het volgende:
Waarom heb je bovenaan de regels met -F input etc na de regels met -P input etc DENY staan? Met -F haal je toch vorige regels weg, maw je maakt die deny regels toch ongedaan?

Een -F(lush) verandert niets aan -P(olicy), het haalt alleen de regels weg die je met bijvoorbeeld -A hebt toegevoegd.

[VROEM!]

Ik heb het script als volgt verbouwd:

code:

#!/bin/sh
echo "Firewalll version 0.1 by eelco"
echo 1 > /proc/sys/net/ipv4/ip_forward
#Flush all
echo "Flushing"
/sbin/ipchains -P input DENY
/sbin/ipchains -P output DENY
/sbin/ipchains -P forward DENY 
/sbin/ipchains -F input
/sbin/ipchains -F output
/sbin/ipchains -F forward
#Modem Traffic
/sbin/ipchains -A input -i eth1 -s 192.168.1.7/24 -d 192.168.1.3/24 -j ACCEPT
/sbin/ipchains -A output -i eth1 -d 192.168.1.3/24 -s 192.168.1.7/24 -j ACCEPT

#Local Traffic
/sbin/ipchains -A input -i lo -j ACCEPT
/sbin/ipchains -A output -i lo -j ACCEPT
/sbin/ipchains -A input -i eth1 -s 192.168.1.0/24 -j ACCEPT
/sbin/ipchains -A output -i eth1 -d 192.168.1.0/24 -j ACCEPT
/sbin/ipchains -A forward -i eth1 -d 192.168.1.0/24 -s 192.168.0.0/24 -j ACCEPT 
/sbin/ipchains -A forward -i eth0 -d 192.168.0.0/24 -s 192.168.1.0/24 -j ACCEPT 

#Internet Traffic
/sbin/ipchains -A input -p icmp -i eth1 -s 0.0.0.0/0 -d 192.168.1.7 -j ACCEPT
/sbin/ipchains -A input -p TCP -i eth1 -s 0.0.0.0/0 -d 192.168.1.7 1024: -j ACCEPT
/sbin/ipchains -A input -p UDP -i eth1 -s 0.0.0.0/0 -d 192.168.1.7 1024: -j ACCEPT
echo "Specifying friends"
#Masquerading

echo "Masqueradig"
/sbin/ipchains -A forward -i eth1 -s 192.168.1.0/24 -j MASQ
/sbin/ipchains -A forward -i eth1 -s 192.168.1.0/24 -d 10.0.0.138 -j MASQ -l

Nog steeds geen ping. Eth1 hangt aan het internet, eth0 is intern met een adres 192.168.1.3, ik probeer te pingen van en naar de windows machine met adres 192.168.1.7, beide subnet 255.255.255.0

[VROEM!]

Ik heb ook maar even eth0 en de windows machine met een cross kabeltje verbonden ipv beide aan de hub. Dit maakt geen verschil voor het pingen.

[VROEM!]

Update: ik krijg nu wel de volgende meldingen met dmesg (standaard win'98 ping actie, dus met 4 paketten gedaan)

Ping windows-->linux (ping 192.168.1.3)

code:

Apr  7 20:33:51 compaq kernel: Packet log: input DENY eth1 PROTO=17 192.168.1.7:138 192.168.1.255:138 L=232 S=0x00 I=55040 F=0x0000 T=128 (#4)
Apr  7 20:34:21 compaq kernel: Packet log: input DENY eth1 PROTO=17 145.94.192.1:67 255.255.255.255:68 L=382 S=0x00 I=65268 F=0x0000 T=255 (#7)
Apr  7 20:34:21 compaq kernel: Packet log: input DENY eth0 PROTO=17 145.94.192.1:67 255.255.255.255:68 L=382 S=0x00 I=65268 F=0x0000 T=255 (#7)

Ping linux-->windows (ping 192.168.1.7)

code:

Apr  7 20:38:43 compaq kernel: Packet log: input DENY eth0 PROTO=17 145.94.196.104:138 145.94.255.255:138 L=229 S=0x00 I=41254 F=0x0000 T=128 (#7)

Er is dus wel iets veranderd. Let even niet op de tijd: de klok van die machine staat niet goed en ik ben te lui om daar iets aan te doen

[VROEM!]

145.94.192.1 is trouwens de DHCP server van babyxl. Waarom komt die er bij tussendoor zeilen?

[Verwijderd]

Geef de huidige output eens van:

code:

ifconfig
route
ipchains -L

Er is namelijk iets heel vreemds aan de hand.
145.94.196.1 (De DHCP-server) wil vanaf z'n bootps poort naar jouw machine verbinden op de bootpc poort. Dit is heel normaal om een lease te hernieuwen etc. Wat niet normaal is, is dat je kernel de input denied op 2!! interfaces. Dit betekent ook dat de input op beide interfaces aan moet komen. (Overigens wil je bootpc/bootps verkeer in beide richtingen naar de DHCP-server sowieso niet blokkeren )

[VROEM!]

ifconfig

code:

eth0    Link encap:Ethernet  HWaddr 00:00:C0:46:D6:95  
        inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:70 errors:0 dropped:0 overruns:0 frame:0
        TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:100 
        Interrupt:5 Base address:0x270 Memory:d0000-d4000 

eth1    Link encap:Ethernet  HWaddr 00:80:5F:9C:EB:E0  
        inet addr:145.94.196.105  Bcast:145.94.255.255  Mask:255.255.192.0
        UP BROADCAST RUNNING  MTU:1500  Metric:1
        RX packets:983 errors:2 dropped:0 overruns:0 frame:4
        TX packets:1106 errors:3 dropped:0 overruns:0 carrier:3
        collisions:3 txqueuelen:100 
        Interrupt:11 Base address:0x1000 

lo    Link encap:Local Loopback  
        inet addr:127.0.0.1  Mask:255.0.0.0
        UP LOOPBACK RUNNING  MTU:3924  Metric:1
        RX packets:4 errors:0 dropped:0 overruns:0 frame:0
        TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:0

route

code:

Kernel IP routing table
Destination     Gateway    Genmask     Flags Metric Ref    Use Iface
192.168.1.0     *          255.255.255.0   U     0  0     0 eth0
145.94.192.0    *          255.255.192.0   U     0  0     0 eth1
default    adslgw-zh.tudel 0.0.0.0     UG    0  0     0 eth1

ipchains -L

code:

Chain input (policy DENY):
target     prot opt     source          destination      ports
ACCEPT     all  ------  anywhere         anywhere         n/a
DENY     all  ----l-  127.0.0.0/8       anywhere          n/a
ACCEPT     all  ------  192.168.1.0/24   anywhere         n/a
DENY     all  ----l-  192.168.1.0/24     anywhere         n/a
ACCEPT     all  ------  anywhere         x196104-1.shuis-s.tudelft.nl  n/a
ACCEPT     all  ------  anywhere         145.94.255.255   n/a
DENY     all  ----l-  anywhere       anywhere         n/a
Chain forward (policy DENY):
target     prot opt     source          destination      ports
MASQ     all  ------  192.168.1.0/24     anywhere         n/a
DENY     all  ----l-  anywhere       anywhere         n/a
Chain output (policy DENY):
target     prot opt     source          destination      ports
ACCEPT     all  ------  anywhere         anywhere         n/a
ACCEPT     all  ------  anywhere         192.168.1.0/24   n/a
ACCEPT    !tcp  ------  anywhere         BASE-ADDRESS.MCAST.NET/4  any ->   any
DENY     all  ----l-  anywhere       192.168.1.0/24   n/a
ACCEPT     all  ------  x196104-1.shuis-s.tudelft.nl anywhere         n/a
ACCEPT     all  ------  145.94.255.255   anywhere         n/a
DENY     all  ----l-  anywhere       anywhere         n/a

Mijn script:

code:

#!/bin/sh
echo "Firewalll version 0.1 by eelco"
echo 1 > /proc/sys/net/ipv4/ip_forward
#Flush all
echo "Flushing"
/sbin/ipchains -P input DENY
/sbin/ipchains -P output DENY
/sbin/ipchains -P forward DENY 
/sbin/ipchains -F input
/sbin/ipchains -F output
/sbin/ipchains -F forward
#Modem Traffic
/sbin/ipchains -A input -i eth0 -s 192.168.1.7/24 -d 192.168.1.3/24 -j ACCEPT
/sbin/ipchains -A output -i eth0 -d 192.168.1.3/24 -s 192.168.1.7/24 -j ACCEPT

#Local Traffic
/sbin/ipchains -A input -i lo -j ACCEPT
/sbin/ipchains -A output -i lo -j ACCEPT
/sbin/ipchains -A input -i eth1 -s 192.168.1.0/24 -j ACCEPT
/sbin/ipchains -A output -i eth1 -d 192.168.1.0/24 -j ACCEPT
/sbin/ipchains -A forward -i eth1 -d 192.168.1.0/24 -s 192.168.1.0/24 -j ACCEPT 
/sbin/ipchains -A forward -i eth0 -d 192.168.1.0/24 -s 192.168.1.0/24 -j ACCEPT 

#Internet Traffic
/sbin/ipchains -A input -p icmp -i eth1 -s 0.0.0.0/0 -d 192.168.1.7 -j ACCEPT
/sbin/ipchains -A input -p TCP -i eth1 -s 0.0.0.0/0 -d 192.168.1.7 1024: -j ACCEPT
/sbin/ipchains -A input -p UDP -i eth1 -s 0.0.0.0/0 -d 192.168.1.7 1024: -j ACCEPT
echo "Specifying friends"
#Masquerading

echo "Masqueradig"
/sbin/ipchains -A forward -i eth1 -s 192.168.1.0/24 -j MASQ
/sbin/ipchains -A forward -i eth1 -s 192.168.1.0/24 -d 10.0.0.138 -j MASQ -l

Hoe laat ik ipchains trouwens het script opnieuw laden zonder herstart?

En nog wat: Ik kan nog steeds met webmin bij die machine, over eth1.

[Buffy]

Hmm, output van ipchains -L zonder the interface (ifname) kolom is nogal verwarrend

[VROEM!]

Dat vind ik ook

Maar ik krijg die kolom er niet bij. Niet als ik het commando invoer bij webmin en niet via ssh. Ook niet direct via de console. Hoe kan ik daar iets aan doen?

[Buffy]

Op zondag 07 april 2002 20:49 schreef VROEM! het volgende:
Dat vind ik ook

Maar ik krijg die kolom er niet bij. Niet als ik het commando invoer bij webmin en niet via ssh. Ook niet direct via de console. Hoe kan ik daar iets aan doen?

in de console:

ipchains -L -v -n



Probeer overigens ook eens in een dos-box op de windows machine het commando:

arp -a

Als je dit vlak na het pingen doet krijg je het MAC adres te zien van linux netwerk kaart waar die naar pingd.
Die zou het zelfde moeten zijn als die in de ifconfig output (HWadress) van je interne network (192.168.1.0).

[VROEM!]

ipchains -L -v -n:

code:

Chain input (policy DENY: 7 packets, 2370 bytes):
 pkts bytes target     prot opt    tosa tosx  ifname     mark    outsize  source            destination      ports
    4   448 ACCEPT     all  ------ 0xFF 0x00  lo                     0.0.0.0/0      0.0.0.0/0        n/a
    0     0 DENY     all  ----l- 0xFF 0x00  !lo                 127.0.0.0/8     0.0.0.0/0        n/a
    1   232 ACCEPT     all  ------ 0xFF 0x00  eth0                 192.168.1.0/24    0.0.0.0/0       n/a
    1   232 DENY     all  ----l- 0xFF 0x00  eth1                   192.168.1.0/24    0.0.0.0/0       n/a
  654  108K ACCEPT     all  ------ 0xFF 0x00  eth1                 0.0.0.0/0        145.94.196.105    n/a
    4   467 ACCEPT     all  ------ 0xFF 0x00  eth1                 0.0.0.0/0        145.94.255.255    n/a
    4   467 DENY     all  ----l- 0xFF 0x00  *                   0.0.0.0/0       0.0.0.0/0        n/a
Chain forward (policy DENY: 1 packets, 48 bytes):
 pkts bytes target     prot opt    tosa tosx  ifname     mark    outsize  source            destination      ports
    0     0 MASQ     all  ------ 0xFF 0x00  eth1                   192.168.1.0/24    0.0.0.0/0       n/a
    0     0 DENY     all  ----l- 0xFF 0x00  *                   0.0.0.0/0       0.0.0.0/0        n/a
Chain output (policy DENY: 6 packets, 1432 bytes):
 pkts bytes target     prot opt    tosa tosx  ifname     mark    outsize  source            destination      ports
    4   448 ACCEPT     all  ------ 0xFF 0x00  lo                     0.0.0.0/0      0.0.0.0/0        n/a
    4   336 ACCEPT     all  ------ 0xFF 0x00  eth0                 0.0.0.0/0        192.168.1.0/24    n/a
    0     0 ACCEPT    !tcp  ------ 0xFF 0x00  eth0                 0.0.0.0/0        224.0.0.0/4      * ->   *
    0     0 DENY     all  ----l- 0xFF 0x00  eth1                   0.0.0.0/0        192.168.1.0/24    n/a
  751  292K ACCEPT     all  ------ 0xFF 0x00  eth1                 145.94.196.105    0.0.0.0/0       n/a
    0     0 ACCEPT     all  ------ 0xFF 0x00  eth1                 145.94.255.255    0.0.0.0/0       n/a
    0     0 DENY     all  ----l- 0xFF 0x00  *                   0.0.0.0/0       0.0.0.0/0        n/a

arp -a zegt geen vermeldingen gevonden. dit is op de win98 testbak waar ik het hier steeds eerder over had. Wel is er op de lijst kernel messages weer een melding bij gekomen:

code:

Packet log: input DENY eth1 PROTO=17 192.168.1.7:138 192.168.1.255:138 L=232 S=0x00 I=60928 F=0x0000 T=128 (#4)

arp-a op de machine waar ik nu op tik geeft drie adressen, maar allemaal in de 145.94.x.x range. Dat zijn de DHCP server, mijn huisgenoot en de linux bak. Degene waar ik nu op werk (145.94.196.107 staat er niet bij.

[VROEM!]

Waarom zijn sommige interfaces trouwens aangegeven met een * en staat er op 1 plek een uitroepteken voor lo?

[odysseus]

Op zondag 07 april 2002 21:38 schreef VROEM! het volgende:
Waarom zijn sommige interfaces trouwens aangegeven met een * en staat er op 1 plek een uitroepteken voor lo?

* = alle interfaces
! = alles behalve deze interface

[VROEM!]

Blokkeert het script dat ik nu gebruik trouwens het pingen naar 192.168.1.3 (eth0)?

Verder vallen me een aantal regels op:

code:

0     0 ACCEPT    !tcp  ------ 0xFF 0x00  eth0                 0.0.0.0/0        224.0.0.0/4      * ->   *

Hoe komt dit adres in de policy?

code:

echo "Masqueradig"
/sbin/ipchains -A forward -i eth1 -s 192.168.1.0/24 -j MASQ
/sbin/ipchains -A forward -i eth1 -s 192.168.1.0/24 -d 10.0.0.138 -j MASQ -l

Hier heb ik de tweede regel niet voldoende bijgewerkt, maar het adres van Trailblazer laten staan. Kan die regel eigenlijk niet gewoon weg?

En nog iets dat ik niet in de manpages heb kunnen vinden: Hoe laat ik mijn bijgewerkte scriptje in werking treden zonder reboot?

[odysseus]

Deze regel staat uitgaand verkeer voor (onder andere) ICMP/ping toe:

code:

    4   336 ACCEPT     all  ------ 0xFF 0x00  eth0                 0.0.0.0/0        192.168.1.0/24    n/a

En deze staat toe dat er ook replies terugkomen:

code:

    1   232 ACCEPT     all  ------ 0xFF 0x00  eth0                 192.168.1.0/24    0.0.0.0/0       n/a

Dus als het goed is worden pings niet geblokkeerd.

[Buffy]

Op zondag 07 april 2002 21:53 schreef VROEM! het volgende:
Blokkeert het script dat ik nu gebruik trouwens het pingen naar 192.168.1.3 (eth0)?

Nee, de derde(?) regel van de input en output chains staat dit toe.
De forward chain blokkeert overigens wel het terug verkeer van de externe netwerk naar je interne netwerk.
En blijkbaar broadcast babyxl-DHCP server op 255.255.255.255 wat je dus blokeert (niet verstandig lijkt me).

De reden waarom die broadcast op beide interfaces binnen komen is natuurlijk omdat ze op 1 hub zitten en daarom probeert je windows doos ook zijn schijven te sharen via de externe interface eth1 (en met de rest van je subnet)

Overigens heeft het geen zin om een firewall machine in te richten als je interne netwerk op de zelfde hub zit als je externe netwerk. dat is je voordeur op slot doen en je achterdeur wagen wijd open zetten.

Verdacht is wel dat de arp cache op je windows doos leeg is na het pingen.

Probeer eens:

route print

en ipconfig

in een dos box.

[VROEM!]

Ah, ok. En die regels met 0.0.0.0/0 betekenen die dat dat elk willekeurig adres mag zijn?

[VROEM!]

Op zondag 07 april 2002 22:13 schreef Dawns_sister het volgende:

[..]

Nee, de derde(?) regel van de input en output chains staat dit toe.
De forward chain blokkeert overigens wel het terug verkeer van de externe netwerk naar je interne netwerk.
En blijkbaar broadcast babyxl-DHCP server op 255.255.255.255 wat je dus blokeert (niet verstandig lijkt me).

Is dat blokkeren van het terug verkeer alleen met de derde regel in het eerste blok?
/sbin/ipchains -P forward DENY
Kan ik die ook veilig (veilig voor als in de computer tussen modem en hub hangt) op ACCEPT zetten? Volgens mij laat ik dan alles toe van binnen naar buiten en vice versa, niet? Wordt het dan ook niet heel makkelijk om straks bij ons binnen te breken?

En waar blokkeer ik die babyxl server precies?

Update: ik heb nu de hierboven genoemde regel op ACCEPT gezet en krijg nog steeds die deny meldingen van de DHCP server.

De reden waarom die broadcast op beide interfaces binnen komen is natuurlijk omdat ze op 1 hub zitten en daarom probeert je windows doos ook zijn schijven te sharen via de externe interface eth1 (en met de rest van je subnet)

Overigens heeft het geen zin om een firewall machine in te richten als je interne netwerk op de zelfde hub zit als je externe netwerk. dat is je voordeur op slot doen en je achterdeur wagen wijd open zetten.

Dat weet ik, maar het is nu (in de test situatie) even het meest practisch. Als dit werkt wil ik het modem met een cross kabel aan eth1 hangen en eth0 aan de hub op het interne netwerk. Dan is het toch weer dicht, niet?

Verdacht is wel dat de arp cache op je windows doos leeg is na het pingen.

Probeer eens:

route print

en ipconfig

in een dos box.

ipconfig:

code:

ip-adres: 192.168.1.7
netmask: 255.255.255.0
standaardgateway: 192.168.1.3

route print op win98: metric is overal 1
Alles na # is door mij verzonnen commentaar

code:

netwerkadres  netmask      gateway  interface
0.0.0.0  0.0.0.0       192.168.1.3  192.168.1.7
127.0.0.0     255.0.0.0  127.0.0.1    127.0.0.1 #localhost linux?
192.168.1.0   255.255.255.0   192.168.1.7  192.168.1.7 #Waarom staat het ip van de windows bak hier als gateway????
192.168.1.7   255.255.255.255 127.0.0.1    127.0.0.1
192.168.1.255 255.255.255.255 192.168.1.7  192.168.1.7 
224.0.0.0     224.0.0.0  192.168.1.7  192.168.1.7
255.255.255.255 255.255.255.255 192.168.1.7 192.168.1.7

route print op XP

code:

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...52 54 ab 1a 80 56 ...... Realtek RTL8029(AS) PCI Ethernet Adapter - Packe
t Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination   Netmask       Gateway  Interface  Metric
        0.0.0.0     0.0.0.0     145.94.192.1  145.94.196.107     30
      127.0.0.0   255.0.0.0   127.0.0.1  127.0.0.1   1
     145.94.192.0    255.255.192.0   145.94.196.107  145.94.196.107  30
   145.94.196.107  255.255.255.255    127.0.0.1  127.0.0.1   30
   145.94.255.255  255.255.255.255   145.94.196.107  145.94.196.107  30
      224.0.0.0   240.0.0.0   145.94.196.107  145.94.196.107     30
  255.255.255.255  255.255.255.255   145.94.196.107  145.94.196.107  1
Default Gateway:    145.94.192.1
===========================================================================
Persistent Routes:
  None

[VROEM!]

Ik krijg trouwens een klein vermoeden dat ik wel dingen zit te wijzigen, maar in het verkeerde bestand. Ik heb nu met de hand het ipchains filter van webmin zitten editen, maar er verandert niks in ipchains -L -n -v.

Hoe controleer ik of linux niet stiekem een ander bestand gebruikt voor het script?

[Buffy]

De routing tabel van de win98 doos ziet er goed uit.

127.0.0.1 is de loopback device van de windos doos een soort echo put.
En dat van die gateway op de derde regel moet je maar aan Bill vragen

Ik heb geen ervaring met webadmin maar je kan het script op de console met

. firewallscript

waarbij firewallscript de naam van het script (inclusief pad) met de ipchains commando's erin. (denk aan de punt)

[VROEM!]

Op zondag 07 april 2002 23:14 schreef Dawns_sister het volgende:
De routing tabel van de win98 doos ziet er goed uit.

127.0.0.1 is de loopback device van de windos doos een soort echo put.
En dat van die gateway op de derde regel moet je maar aan Bill vragen

Ik heb geen ervaring met webadmin maar je kan het script op de console met

. firewallscript

waarbij firewallscript de naam van het script (inclusief pad) met de ipchains commando's erin. (denk aan de punt)

Oke, dan krijg ik flushing, specifying friends, masquerading en dan weer de prompt. Kortom alle echo commando's. (o joepie ik heb iets gesnapt )

Maar nog steeds geen ping van en naar de linux box over eth0. Sterker nog: eth1 is nu ook dicht

[Buffy]

Op zondag 07 april 2002 23:27 schreef VROEM! het volgende:

[..]

Oke, dan krijg ik flushing, specifying friends, masquerading en dan weer de prompt. Kortom alle echo commando's. (o joepie ik heb iets gesnapt )

Maar nog steeds geen ping van en naar de linux box over eth0. Sterker nog: eth1 is nu ook dicht

Klopt, het script wat je gebruikt heb is voor een adsl-modem. eth1 is nu alleen geschikt voor communicatie met het modem

Sorry, had ik niet eerder opgemerkt

[VROEM!]

Op zondag 07 april 2002 23:45 schreef Dawns_sister het volgende:

[..]

Klopt, het script wat je gebruikt heb is voor een adsl-modem. eth1 is nu alleen geschikt voor communicatie met het modem

Sorry, had ik niet eerder opgemerkt

Eikel Hoe krijg ik dat nu goed? Ik wil dus dat hij zowel met een adsl modem als met een gewone netwerkkaart kan communiceren. Aangezien eth0 nog steeds potjedicht zit moet ik dus wel dingen kunnen doen via eth1.

Nog hieronder even mijn scriptje om minder te hoeven bladeren...

code:

#!/bin/sh
echo "Firewalll version 0.1 by eelco"
echo 1 > /proc/sys/net/ipv4/ip_forward
#Flush all
echo "Flushing"
/sbin/ipchains -P input DENY
/sbin/ipchains -P output DENY
/sbin/ipchains -P forward ACCEPT
/sbin/ipchains -F input
/sbin/ipchains -F output
/sbin/ipchains -F forward

echo "Setting up modem traffic" 
#Modem Traffic
/sbin/ipchains -A input -i eth0 -s 192.168.1.7/24 -d 192.168.1.3/24 -j  ACCEPT
/sbin/ipchains -A output -i eth0 -d 192.168.1.3/24 -s 192.168.1.7/24 -j  ACCEPT

echo " Setting up local traffic"
#Local Traffic
/sbin/ipchains -A input -i lo -j  ACCEPT
/sbin/ipchains -A output -i lo -j  ACCEPT
/sbin/ipchains -A input -i eth1 -s 192.168.1.0/24 -j  ACCEPT
/sbin/ipchains -A output -i eth1 -d 192.168.1.0/24 -j  ACCEPT
/sbin/ipchains -A forward -i eth1 -d 192.168.1.0/24 -s 192.168.1.0/24 -j  ACCEPT 
/sbin/ipchains -A forward -i eth0 -d 192.168.1.0/24 -s 192.168.1.0/24 -j  ACCEPT 

echo "Setting up internet traffic"
#Internet Traffic
/sbin/ipchains -A input -p icmp -i eth1 -s 0.0.0.0/0 -d 192.168.1.7 -j  ACCEPT
/sbin/ipchains -A input -p TCP -i eth1 -s 0.0.0.0/0 -d 192.168.1.7 1024: -j  ACCEPT
/sbin/ipchains -A input -p UDP -i eth1 -s 0.0.0.0/0 -d 192.168.1.7 1024: -j  ACCEPT

echo "Specifying friends"
#Masquerading

echo "Masquerading"
/sbin/ipchains -A forward -i eth1 -s 192.168.1.0/24 -j  MASQ
#/sbin/ipchains -A forward -i eth1 -s 192.168.1.0/24 -d 10.0.0.138 -j -b MASQ -l

Ik zie nu ff iets:

Moet eth0 onder het kopje modem traffic niet eth1 zijn? Eth1 moet met het modem kletsen. eth0 is voor intern netwerk.
* VROEM! krijgt het vermoeden dat er wel meer eth1 en eth0 dingen omgedraaid zijn....klopt dit?
Het begint me nu net allemaal een beetje te dagen, maar ik kan eigenlijk nog niet het overzicht houden over zo'n script.

[VROEM!]

Maar even wat anders: als ik alles flush en de policy van alles op ACCEPT zet, is eth0 ook niet te pingen. Zit dan de oorzaak niet ergens buiten het firewall script?

[Buffy]

Probeer deze eens:

#!/bin/sh

VERBOSE="-l"
INTIF="eth0"
EXTIF="eth1"

echo "Firewalll version 0.1 by Buffy"
echo 1 > /proc/sys/net/ipv4/ip_forward

#Flush all
echo "Flushing"

/sbin/ipchains -P input DENY
/sbin/ipchains -P output DENY
/sbin/ipchains -P forward DENY
/sbin/ipchains -F input
/sbin/ipchains -F output
/sbin/ipchains -F forward

#Local Traffic
echo "Local traffic"

/sbin/ipchains -A input -i lo -j ACCEPT
/sbin/ipchains -A output -i lo -j ACCEPT
/sbin/ipchains -A input -i $INTIF -s 192.168.1.0/24 -j ACCEPT $VERBOSE
/sbin/ipchains -A output -i $INTIF -d 192.168.1.0/24 -j ACCEPT $VERBOSE


#Internet Traffic
echo "Internet Traffic"
/sbin/ipchains -A input -i $EXTIF -s 145.94.192.1/32 -j ACCEPT $VERBOSE
/sbin/ipchains -A input -i $EXTIF -s 0.0.0.0/0 -d 145.94.196.105/32 -j ACCEPT $VERBOSE
/sbin/ipchains -A output -i $EXTIF -s 145.94.196.105/32 -d 0.0.0.0/0 -j ACCEPT $VERBOSE


#Masquerading
echo "Masqueradig"
/sbin/ipchains -A forward -i $EXTIF -s 192.168.1.0/24 -j MASQ $VERBOSE


#Overbodig indien niet verbose
echo "Hekken sluiter"
/sbin/ipchains -A input -j DENY $VERBOSE
/sbin/ipchains -A output -j DENY $VERBOSE
/sbin/ipchains -A forward -j DENY $VERBOSE


Dit is overigens niet een echt "veilige" firewall setup

PS: het is wel een tijdje geleden dat ik met IPCHAINS heb gewerkt. Gebruik nu iptables (kernel 2.4.x) en dat zit net ietsje anders in elkaar. Vandaar de verwaring.

[Verwijderd]

Hmzz, even een opmerking van mijn kant...

Kan je hub wel goef functioneren met 2 verschillende subnets? Bij mijn weten kunnen maar weinig hubs dit itt switches.

Trek je ISP kabel er eens uit en probeer dan eens te pingen.

[VROEM!]

Ik doe het ff anders: Op de hub zit nu alleen het subnet van mijn ISP. De linux bak zit aan de hub (waar ik ook aan zit) en het windows teststation zit met een cross-kabel aan eth0.

Dat kan toch ook, niet?

* VROEM! stelt ook maar even wat noob vragen, omdattie nergens meer zeker van is op dit moment

Update: kabeltruuk samen met scriptwissel hebben geen effect.

[VROEM!]

Update: ze hebben wel effect

Ik kkrijg nu de melding dat de input op eth0 van 192.168.1.7 geaccepteerd is, maar krijg op de windows bak nog geen reply!

[deadinspace]

Merk op dat een crosskabel niet altijd werkt; sommige netwerkkaarten vinden elkaar niet zo lief als ze met een crosskabel verbonden zijn.

[VROEM!]

Op maandag 08 april 2002 00:55 schreef deadinspace het volgende:
Merk op dat een crosskabel niet altijd werkt; sommige netwerkkaarten vinden elkaar niet zo lief als ze met een crosskabel verbonden zijn.

Ga ik effe testen...nu dus ISP kabels eruit, windows kabel eruit en eth1 kaart eruit. eth0 en windows testbak kabel erin en pingen...

Dat hielp dus ook niet. Het aantal meldingen met geaccepteerde packets loopt wel op, maar er komt nog geen reply op pings

[Buffy]

Op maandag 08 april 2002 00:42 schreef VROEM! het volgende:
Ik doe het ff anders: Op de hub zit nu alleen het subnet van mijn ISP. De linux bak zit aan de hub (waar ik ook aan zit) en het windows teststation zit met een cross-kabel aan eth0.

Dat kan toch ook, niet?

Yep

* VROEM! stelt ook maar even wat noob vragen, omdattie nergens meer zeker van is op dit moment

Ik heb een keer een week lang met het zelfde probleem zitten klooien. Tot ik opeens zag dat ik op de windows bak een type fout had gemaakt. 192.186.1.6 als gateway ipv 192.168.1.6
Toen voelde ik me ook een n00b

Update: kabeltruuk samen met scriptwissel hebben geen effect.

En na script wissel nog leuke meldingen?
Bv als je vanaf de linux bak pinged.

[VROEM!]

linux->windows = alleen packet loss
windows-> linux = alleen packet accept, geen reply

De linux bak ontvangt dus wel, maar stuurt niet.

Wat doen die laatste drie regels van jou trouwens?

#Overbodig indien niet verbose
echo "Hekken sluiter"
/sbin/ipchains -A input -j DENY $VERBOSE
/sbin/ipchains -A output -j DENY $VERBOSE
/sbin/ipchains -A forward -j DENY $VERBOSE

[Buffy]

Op maandag 08 april 2002 01:02 schreef VROEM! het volgende:
linux->windows = alleen packet loss
windows-> linux = alleen packet accept, geen reply

De linux bak ontvangt dus wel, maar stuurt niet.

En geen log meldingen van de firewall?
In mijn script staat alles het goed is (bijna) overal de -l (log) optie achter.

-Edit-
Die laatste drie zorgen ervoor dat alle gedropte pakketjes gelogd worden.

[VROEM!]

Ik krijg wel allerlei meldingen van geaccepteerde packets.

Van een aantal adressen:
145.94.196.107 (ik)
145.94.196.105 (linux)
En ook een paar van een 195.x.x.x.x adres (ben ze effe kwijt)

Worden die meldingen nog in een logbestandje bijgehouden?

[VROEM!]

[..]
Dit is overigens niet een echt "veilige" firewall setup

Dat boeit me op dit moment ff eerlijk gezegd niet zo...eerst contact leggen en dan verder zien.

Ik ga nu trouwens tukken. Morgen komt ie aan een andere hub en dan wil ik nog eens kijken wat er dan gebeurt. Het is mooi geweest voor vandaag. Bedankt tot zover!

[Buffy]

Op maandag 08 april 2002 01:17 schreef VROEM! het volgende:
Ik krijg wel allerlei meldingen van geaccepteerde packets.

Van een aantal adressen:
145.94.196.107 (ik)
145.94.196.105 (linux)
En ook een paar van een 195.x.x.x.x adres (ben ze effe kwijt)

Worden die meldingen nog in een logbestandje bijgehouden?

Hmm, ligt eraan hoe en of syslog geconfigureerd is.
Bij mij komen ze in /var/log/syslog en /var/log/kern.log terecht (Debian distributie).

Kijk eens in /etc/syslog.conf in welke bestand de log meldingen *.* en/of kern.* terecht komen (*.* betekent alle en kern.* alle kernel meldingen).

[VROEM!]

Ze komen in kern.log. Dat is zeker ook degene die afgespeeld wordt als je dmesg intypt?

[VROEM!]

Dit vond ik nu in mijn log na een ping van de linux machine naar de windows bak (over een cross kabel)

code:

Apr  8 09:34:34 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=980 F=0x0000 T=64 (#2)
Apr  8 09:34:35 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=981 F=0x0000 T=64 (#2)
Apr  8 09:34:36 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=982 F=0x0000 T=64 (#2)
Apr  8 09:34:37 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=986 F=0x0000 T=64 (#2)
Apr  8 09:34:38 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=987 F=0x0000 T=64 (#2)
Apr  8 09:34:39 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=988 F=0x0000 T=64 (#2)
Apr  8 09:35:06 compaq kernel: Packet log: input ACCEPT eth1 PROTO=6 145.94.196.107:1432 145.94.196.105:10000 L=40 S=0x00 I=4370 F=0x4000 T=128 (#4)
Apr  8 09:35:06 compaq kernel: Packet log: input ACCEPT eth1 PROTO=6 145.94.196.107:1436 145.94.196.105:10000 L=40 S=0x00 I=4371 F=0x4000 T=128 (#4)
Apr  8 09:36:31 compaq kernel: Packet log: input ACCEPT eth0 PROTO=17 192.168.1.7:138 192.168.1.255:138 L=232 S=0x00 I=30720 F=0x0000 T=128 (#2)
Apr  8 09:36:31 compaq kernel: Packet log: input ACCEPT eth0 PROTO=17 192.168.1.7:137 192.168.1.255:137 L=78 S=0x00 I=30976 F=0x0000 T=128 (#2)
Apr  8 09:36:31 compaq kernel: Packet log: input ACCEPT eth0 PROTO=17 192.168.1.7:137 192.168.1.255:137 L=78 S=0x00 I=31232 F=0x0000 T=128 (#2)
Apr  8 09:36:32 compaq kernel: Packet log: input ACCEPT eth0 PROTO=17 192.168.1.7:137 192.168.1.255:137 L=78 S=0x00 I=31488 F=0x0000 T=128 (#2)
Apr  8 09:39:01 compaq kernel: Packet log: input ACCEPT eth0 PROTO=17 192.168.1.7:138 192.168.1.255:138 L=232 S=0x00 I=33280 F=0x0000 T=128 (#2)

dus er gaat wel iets heen en weer zou je zeggen. Waarom komt er dan geen reply op de ping?

De output gaat trouwens over poort 0 lijkt het. Is dat normaal voor een ping?

[TrailBlazer]

Op zondag 07 april 2002 17:42 schreef VROEM! het volgende:

[..]

Ik heb wat vragen over de IP adressen:
Welke is van welke kaart en welke zijn van andere computers dan je server? Alles dat eindigt op .0/24 is als het goed is van je interne netwerk met een netmask van 255.255.255.0

klopt alles in de reeks .0/24 is intern werkstation .1/24 zijn al mijn servers (nog maar een )

Verder: Waarom heb je bovenaan de regels met -F input etc na de regels met -P input etc DENY staan? Met -F haal je toch vorige regels weg, maw je maakt die deny regels toch ongedaan?

is reeds uitgelgd en staat in de ip masquerading faq geloof ik .

Als laatste: die adressen met 0.0.0.0, is dat wat je invult als je kaart zijn instellingen met DHCP op moet halen?

nee mijn ADSL modem stuurt alles van het internet door naar mijn kaartje (eth2) met ip 10.0.0.100. DIt heeft als source 0.0.0.0/0 alles dus. Ik had geen zin om elk adres handmatig in te stellen

Als laatste+1 : Ik blokkeer toch geen verkeer van intern met ssh via dit script? Dat moet voorlopig nog wel effe gehandhaafd blijven.

nee dat doe je niet met de regels onder local traffic specificieer je dat het verkeer van en naar de beide locale segmenten vrij mag gaan

[VROEM!]

Is het trouwens mogelijk om 2 netwerkkaarten hetzelfde subnetmask te geven? Ik meen me te herinneren dat dat problemen zou kunnen geven, maar wellicht lost het nu e.e.a op als mijn hub slecht met meerdere subnetten overweg kan.

[TrailBlazer]

Op maandag 08 april 2002 10:41 schreef VROEM! het volgende:
Is het trouwens mogelijk om 2 netwerkkaarten hetzelfde subnetmask te geven? Ik meen me te herinneren dat dat problemen zou kunnen geven, maar wellicht lost het nu e.e.a op als mijn hub slecht met meerdere subnetten overweg kan.

het subnetmasker wel. Dat heb je namelijk al twee netwerkkaarten die in hetzelfde netwerk vallen kan wel maar dat wil je in dit geval niet. bovendien met een crosswerkte het ook niet dus daar zit het niet in.

[VROEM!]

Op maandag 08 april 2002 11:11 schreef TrailBlazer het volgende:

[..]

het subnetmasker wel. Dat heb je namelijk al twee netwerkkaarten die in hetzelfde netwerk vallen kan wel maar dat wil je in dit geval niet. bovendien met een crosswerkte het ook niet dus daar zit het niet in.

Ik was niet specifiek genoeg: twee netwerkkaarten met hetzelfde netmask in 1 computer

[TrailBlazer]

Op maandag 08 april 2002 12:48 schreef VROEM! het volgende:

[..]

Ik was niet specifiek genoeg: twee netwerkkaarten met hetzelfde netmask in 1 computer

je ziet het verschil niet tussen netmask en netwerk.
Lees dit eens door
[topic=457500]

[Buffy]

Op maandag 08 april 2002 08:37 schreef VROEM! het volgende:
Dit vond ik nu in mijn log na een ping van de linux machine naar de windows bak (over een cross kabel)
Apr 8 09:34:34 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=980 F=0x0000 T=64 (#2)
Apr 8 09:34:35 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=981 F=0x0000 T=64 (#2)
Apr 8 09:34:36 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=982 F=0x0000 T=64 (#2)
Apr 8 09:34:37 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=986 F=0x0000 T=64 (#2)
Apr 8 09:34:38 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=987 F=0x0000 T=64 (#2)
Apr 8 09:34:39 compaq kernel: Packet log: output ACCEPT eth0 PROTO=1 192.168.1.3:8 192.168.1.7:0 L=84 S=0x00 I=988 F=0x0000 T=64 (#2)

Ping pakketjes van linux naar windows.

Apr 8 09:35:06 compaq kernel: Packet log: input ACCEPT eth1 PROTO=6 145.94.196.107:1432 145.94.196.105:10000 L=40 S=0x00 I=4370 F=0x4000 T=128 (#4)
Apr 8 09:35:06 compaq kernel: Packet log: input ACCEPT eth1 PROTO=6 145.94.196.107:1436 145.94.196.105:10000 L=40 S=0x00 I=4371 F=0x4000 T=128 (#4)

XP?

Apr 8 09:36:31 compaq kernel: Packet log: input ACCEPT eth0 PROTO=17 192.168.1.7:138 192.168.1.255:138 L=232 S=0x00 I=30720 F=0x0000 T=128 (#2)
Apr 8 09:36:31 compaq kernel: Packet log: input ACCEPT eth0 PROTO=17 192.168.1.7:137 192.168.1.255:137 L=78 S=0x00 I=30976 F=0x0000 T=128 (#2)
Apr 8 09:36:31 compaq kernel: Packet log: input ACCEPT eth0 PROTO=17 192.168.1.7:137 192.168.1.255:137 L=78 S=0x00 I=31232 F=0x0000 T=128 (#2)
Apr 8 09:36:32 compaq kernel: Packet log: input ACCEPT eth0 PROTO=17 192.168.1.7:137 192.168.1.255:137 L=78 S=0x00 I=31488 F=0x0000 T=128 (#2)
Apr 8 09:39:01 compaq kernel: Packet log: input ACCEPT eth0 PROTO=17 192.168.1.7:138 192.168.1.255:138 L=232 S=0x00 I=33280 F=0x0000 T=128 (#2)

dus er gaat wel iets heen en weer zou je zeggen. Waarom komt er dan geen reply op de ping?

Netbios "broadcast" van win98 bak.

Er komt dus wel iets binnen over eth0 op de linux bak.
Het lijkt erop dat win98 de netwerkkaart van de linux bak niet hoort.
Dat zou ook verklaren waarom de arp cache op de win98 bak leeg is na een ping poging van win -> linux.

Probeer eens de netwerk kaarten van de win98 en linux bak om te wisselen. Misschien draait het "probleem" zich dan ook om.

De output gaat trouwens over poort 0 lijkt het. Is dat normaal voor een ping?

Het ICMP protocal (PROTO=1) werkt niet echt met poorten. Betreft een pakketje met icmp-type 8 (ping) en de andere kant moet daar met icmp-type 0 (pong) op antwoorden.
Ipchians geeft dat in de log weer met source port 8 en destination port 0 maar dat is een beetje misleidend.

[odysseus]

Op maandag 08 april 2002 01:02 schreef VROEM! het volgende:
linux->windows = alleen packet loss
windows-> linux = alleen packet accept, geen reply

De linux bak ontvangt dus wel, maar stuurt niet.

Wat is de uitvoer van 'cat /proc/sys/net/ipv4/icmp_echo_ignore_*'? Je linuxbak zou ingesteld kunnen hebben om niet op echo-requests te antwoorden. Dat zou verklaren waarom de pings wel aankomen, maar er geen pongs verstuurd worden.

[TrailBlazer]

Op maandag 08 april 2002 14:49 schreef Dawns_sister het volgende:
Het ICMP protocal (PROTO=1) werkt niet echt met poorten. Betreft een pakketje met icmp-type 8 (ping) en de andere kant moet daar met icmp-type 0 (pong) op antwoorden.
Ipchians geeft dat in de log weer met source port 8 en destination port 0 maar dat is een beetje misleidend.

hee koel dit wist ik niet. Ik heb overigens ook nog nooit gelogged op pings. Ik denk dat ik dan best wel eenbeetje gek zou worden.

[VROEM!]

Op maandag 08 april 2002 15:44 schreef odysseus het volgende:

[..]

Wat is de uitvoer van 'cat /proc/sys/net/ipv4/icmp_echo_ignore_*'? Je linuxbak zou ingesteld kunnen hebben om niet op echo-requests te antwoorden. Dat zou verklaren waarom de pings wel aankomen, maar er geen pongs verstuurd worden.

Uitvoer is
0
0

Na een ping van linux-->windows.

Na andersom:
0
0

[VROEM!]

Ik heb hem nu trouwens aan een andere hub (degene in de meterkast, de eerste was op mijn kamer)

Situatie is nu als volgt: Hij wilde eerst nog wel mijn computer zien, maar nu niet meer. Wel nog die van mijn huisgenoten.

Computers met adressen in de 192.168.1.x range wil hij niet pingen en wil hij niet door gepingd worden. Ook wil hij nu niet meer door mijn computer gezien worden. Met firewall up en plat is er geen verschil, ik kom er niet meer bij.

Computers die direct aan de hub in de meterkast zitten met een ip adres in de 145.x.x.x range worden wel gepingd. Ook computers van buiten huis kan hij pingen.

Mijn computer (op mijn kamer, winXP) met 145.x.x.x IP kan mijn huisgenoot (win98) probleemloos pingen en ik zit nu ook op internet.

Verder kan de windows '98 testbak prima een debian linux bak (zelfde CD voor de install gebruikt als op dat probleemgeval, alle dezelfde zelfde iface config als de probleembak op het IP adres na) die op de hub in de meterkast zit pingen. Beide hebben een adres in de 192.168.1.x range. Terug pingen gaat ook goed.

Nota bene: Die windows testbak en de linux bak die wel te pingen is hebben dezelfde ethernetkaarten als de probleemkaart....