[Linux] Vreemd masq probleem

[Verwijderd]

hallo,

ik heb een vreemd probleem met betrekking tot ip masquerading.
icmp masq werkt prima, tcp masq werkt niet, maar als ik iptraf/tcpdump opstart
werkt tcp masq ineens ook als een trein!

het is een server met een 2.2.25 kernel.
verkeer vanaf het lokale netwerk moet worden gemasq'd over een dsl lijn.
de configuratie van de interfaces, dns, firewall/masq en routing lijken in orde.
beide netwerk-interfaces hebben een mtu van 1500 en firewall laat icmp type 3
door voor mtu discovery.
in /proc staat forwarding enabled, evenals always_defraq en syncookies.

wat kan ik er verder over zeggen, ik heb al vaker zulke servers geconfigureerd
en nooit problemen gehad, ik tast nu in het duister!
een enkeling lijkt het probleem te kennen (via google news-search),
maar oplossingen worden niet genoemd.

tips of aanwijzigingen om dit probleem te debuggen of fixen zijn zeer welkom.

[Verwijderd]

Lijkt me handig dat je ook even aangeeft met welk commando je masqerading laadt. Dus post even de relevante stukken van je firewall/masquerading:)

[Verwijderd]

code:

echo 1 > /proc/sys/net/ipv4/ip_always_defrag
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/ip_forward

code:

modprobe ip_masq_ftp

code:

ipchains -A forward -j MASQ -s 192.168.0.0/24
ipchains -M -S 7200 10 160

[Verwijderd]

Bij Masq moet je ook een interface opgeven:

Dit is mijn masq regel:

external_interface="eth2"
internal_network1="192.168.1.0/24"

ipchains -A forward -i $external_interface -s $internal_network1 -j MASQ

[ Voor 13% gewijzigd door Verwijderd op 12-04-2003 16:24 ]

[Verwijderd]

Verwijderd schreef op 12 April 2003 @ 16:19:
Bij Masq moet je ook een interface opgeven:

Voor zover ik weet wordt verkeer dat in geen van de lokale subnetten thuishoort gemasq'd en gewoon naar de default-gateway doorgestuurd, welke ik definieer in de netwerk configfiles.

Ik geef eerlijk gezegd nooit een interface op bij masq, en het werkt altijd.

Ook al was dit het probleem, verklaart het nog niet waarom icmp masq wel goed gaat, en tcp masq ineens ook wanneer iptraf/tcpdump draait, toch?

[Verwijderd]

Wat geeft ipchains -L voor output?

Netwerk interface staat niet in de promicious mode?

Draait er nog VPN software o.id.?

Wat gebeurt er als je alle regels comment in host.deny en host.allow?

Werkt het wel als je alle andere netwerk gerelateerde software even stopt (behalve netwerk zelf en ipchains)?

[ Voor 10% gewijzigd door Verwijderd op 12-04-2003 18:54 ]

[Verwijderd]

Verwijderd schreef op 12 April 2003 @ 18:52:
Wat geeft ipchains -L voor output?

code:

 ~# ipchains -L -n
Chain input (policy DENY):
target     prot opt     source                destination           ports
ACCEPT     all  ------  0.0.0.0/0            0.0.0.0/0             n/a
ACCEPT     all  ------  0.0.0.0/0            0.0.0.0/0             n/a
REJECT     tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   113
REJECT     tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   3306
REJECT     tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   3128
ACCEPT     tcp  !y----  0.0.0.0/0            0.0.0.0/0             * ->   *
ACCEPT     tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   21
ACCEPT     tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   22
ACCEPT     tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   80
ACCEPT     tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   85
ACCEPT     tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   143
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             0 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             3:4 ->   *
ACCEPT     icmp ------  0.0.0.0/0            0.0.0.0/0             11:12 ->   *
ACCEPT     tcp  ------  0.0.0.0/0            0.0.0.0/0             * ->   1024:65535
ACCEPT     udp  ------  0.0.0.0/0            0.0.0.0/0             * ->   1024:65535
Chain forward (policy DENY):
target     prot opt     source                destination           ports
MASQ       all  ------  192.168.0.0/24       0.0.0.0/0             n/a
Chain output (policy ACCEPT):

Netwerk interface staat niet in de promicious mode?

Nee, geen van de interfaces staat in promisc, niet in de config, en gecontroleerd met ifconfig.
In de config van iptraf (die wellicht tcpdump gebruikt) staat het eveneens uit.

Draait er nog VPN software o.id.?

Nee, de server is redelijk eenvoudig, gewoon internet services als imap, smtp, pop3, http, dns, dhcp, ftp etc.
De server fungeert ook als PDC.

Wat gebeurt er als je alle regels comment in host.deny en host.allow?

Ik gebruik geen tcp wrappers, in de files staat alleen wat commentaar, dus geen regels die actief zijn.

Werkt het wel als je alle andere netwerk gerelateerde software even stopt (behalve netwerk zelf en ipchains)?

Geen idee, maar dit kan ik niet makkelijk testen omdat ik echt afspraken moet maken voor fysiek toegang tot de server, en overdag wordt ie sowieso gebruikt door alle werknemers van het bedrijf.

[Verwijderd]

Deze regel vind ik een beetje vreemd en komen ook niet in mijn ipchains -L -n output terug:

ACCEPT tcp !y---- 0.0.0.0/0 0.0.0.0/0 * -> *

Als je alle chains flushed en delete en je start masq alleen met de volgende regel op de command line, werkt het dan wel?

ipchains -A forward -j MASQ -s 192.168.0.0/24

[Verwijderd]

Verwijderd schreef op 12 April 2003 @ 20:21:
Deze regel vind ik een beetje vreemd en komen ook niet in mijn ipchains -L -n output terug:

ACCEPT tcp !y---- 0.0.0.0/0 0.0.0.0/0 * -> *

Als je alle chains flushed en delete en je start masq alleen met de volgende regel op de command line, werkt het dan wel?

ipchains -A forward -j MASQ -s 192.168.0.0/24

Het spijt me, maar ik heb geen reden aan te nemen dat dit een firewall probleem is.
De betreffende regel houdt in dat tcp verkeer met ack-bit ge-set door wordt gelaten. Bij het opzetten van een tcp connect zullen alle behalve het 1e pakket het ack-bit hebben, dus binnenkomend tcp met ack-bit zal altijd betekenen dat het een bestaande connect is die door een host op het interne netwerk geinitieerd is, tenzij het een netwerk service betreft die vanaf buiten (syn-bit) expliciet geconnect mag/kan worden. Deze manier lijkt misschien onveilig omdat alles dat maar een ack-bit heeft door wordt gelaten, maar als de kernel geen bestaande connect kan vinden bij het pakket zal hij worden gedropd, een tcp connect kan namelijk alleen worden opgebouwd met een syn-bit vooraf. Zeg maar een soort van work-around omdat kernel 2.2 nog geen stateful packetfiltering capabilities heeft.
Deze regel lijkt misschien wat tegenstrijdig omdat ik unprivileged ook al open heb staan, maar dit had ik nodig voor active ftp servers op het internet, en passive ftp capabilitities voor de ftp daemon op de server zelf.
Ik wil je advies evengoed wel een keer uit proberen, maar dan nog, deze firewall komt van de oude server af en heeft nooit problemen opgeleverd, en dan nog verklaart het niet waarom iptraf/tcpdump invloed heeft op het probleem.

[Verwijderd]

Ik zit zelf te denken aan een MTU probleem ofzo, dat icmp/ping wel werkt omdat dat kleine packets zijn en dus niet gefragmenteerd hoeven te worden, weet iemand hier meer over?

[Jaap-Jan]

De MTU kun je bekijken met het commando 'ifconfig'.

[Verwijderd]

Vrotogel, is het misschien een idee dat deze gekickt wordt naar advanced networking?
Aangezien het (voor mij althans) niet duidelijk is of dit wel een probleem is dat direct gerelateerd is aan linux?

[Verwijderd]

Japie_17 schreef op 13 april 2003 @ 12:19:
De MTU kun je bekijken met het commando 'ifconfig'.

Zie eerste posting: beide netwerk-interfaces hebben een mtu van 1500.
Dit lijkt me in orde, maar toch klopt er iets niet waardoor het niet werkt.