Iptables: Logs lopen vol met portforwarding

[arnova]

Ik draai thuis een eigen Iptables-script op mijn Linux server die voor NAT'd voor mijn Windows machines (NB: Ik heb ADSL met een statisch IP). Nou heb ik een paar rules toegevoegd zodat ik de listenport voor gnutella (bearshare) kan forwarden naar mijn Windows bak => werkt allemaal prima. Ik zie alleen in mijn firewall-log dat er allemaal pakketjes geDROPed worden met source-port 6346 (gnutella port). Ik heb geen flauw idee waardoor dit veroorzaakt wordt. Ook al werkt het forwarden, mijn firewall-logs lopen helemaal vol met:

Mar 19 08:18:49 prometheus kernel: Connection attempt: IN=ppp0 OUT= MAC= SRC=130.239.61.163 DST=x.x.x.x LEN=40 TOS=0x00
PREC=0x00 TTL=109 ID=50373 PROTO=TCP SPT=6346 DPT=1878 WINDOW=0 RES=0x00 ACK RST URGP=0

en ook (maar in minder mate) met:

Mar 18 17:04:03 prometheus kernel: New connect without SYN: IN=ppp0 OUT= MAC= SRC=4.43.234.89 DST=x.x.x.x LEN=48 TOS=0x0
0 PREC=0x00 TTL=105 ID=43283 DF PROTO=TCP SPT=6346 DPT=2821 WINDOW=17520 RES=0x00 ACK SYN URGP=0
M

Weet iemand hoe ik dit op kan lossen?

[Kees]

Logging uitzetten voor je NAT ?

[arnova]

Uitzetten, das een goeie. Ik zou nou juist willen weten wat de *oorzaak* van dit probleem is.

[Creepy]

Oorzaak kan vanalles zijn, maar ligt 9 van de 10 keer buiten je eigen bereik om op te lossen. (zoals portscans e.d.)

[arnova]

Maar dit zijn dus GEEN portscans het zijn verbindingen waarvan "de andere kant" nog denkt dat ze in stand zijn terwijl mijn eigen machine dat niet vindt.

[Verwijderd]

valt op dat die twee verbindingen je op verschillende poorten proberen te bereiken (wel zelfde source poort).

Laat anders ff je iptables configuratie zien.

Ik weet ook totaal niet hoe gnutella netwerk precies werkt. Misschien wordt er op die bekende poort alleen gelistened waarna de andere kant op een andere poort een verbinding probeert op te zetten? (ik lul ook maar wat... )

[Verwijderd]

Leuk dat er wat gelogd wordt, maar weet je ook wat er precies gebeurt?
Ik bedoel, ik gok dat jij een verbinding probeertt op te zetten naar een gnutella "server" die op 6346 draait.
Jouw client gaat eerst een connectie aan vanaf 1878, de tweede keer vanaf 2821. Jouw client stuurt een syn pakketje.
De server zal een syn en een ack terugsturen, en jouw client stuurt weer een ack. Daarna is de verbinding opgezet en kan de data gestuurd worden.
Dit is het ideale geval.

De eerste keer krijg je een ack en een rst (reset) terug, wat betekent; permission denied.
In het tweede geval krijg je een ack en een syn terug, maar je firewall ziet het als een nieuwe verbinding, terwijl de tcp-handshake al bezig was. Hier gaat dus iets mis in je connection tracking (?)


Mjah, wat ik hier doe is nogal gokwerk.
Handiger is het als je je firewall script even post.
(zeker nu we je ipadres al hebben gezien, gni gni

[arnova]

Mun IP-adress...ja dat was dus niet zo handig nee (inmiddels veranderd).

Het heeft dus duidelijk iets te maken met hoe die sharing clients werken want ik zie hetzelfde verschijnsel op mijn Linux bak bij mij op de universiteit (Leiden) die dus direct aan het internet zit.

Daar heb ik namelijk eDonkey draaien en lijkt hetzelfde verschijnsel te geven aangezien de source-port dus altijd hetzelfde is (de listen-port van de tegenpartij).

Ik weet echter niet genoeg van TCP om echt te kunnen begrijpen wat er mis gaat.

Btw. voor de geinteresseerden: Die firewall van mij is trouwens behoorlijk uitgebreid en wou ik binnenkort (als dit probleem er dus uit is) releasen (GPL) ben er inmiddels al een half jaar mee bezig. Omdat het een devel is zal ik waarschijnlijk morgen een link hier zetten naar mijn ftp met een public-beta-versie.

[arnova]

Ok, ik heb de problemen grotendeels opgelost. Daarom heb ik em nu als beta gereleased bij freshmet.

De link is:
http://freshmeat.net/projects/iptables-firewall/?topic_id=151

Voor diegenen die nog eens naar mijn probleem willen kijken. Ik heb het (tijdelijk) opgelost door de volgende rules:

$IPTABLES -A CHECK -i $EXT_IF -p tcp --dport $UNPRIV_PORTS --sport 1:9999 ! --syn -j DROP
$IPTABLES -A CHECK -i $EXT_IF -p udp --dport $UNPRIV_PORTS --sport 1:9999 -j DROP

UNPRIV_PORTS=1024:65000