[FreeBSD] ipfilter - problemy (network unreachable a mnoho dalsich)

Zdar, zvazoval jsem jestli to dat do siti, ale tady si to snad precte nekdo povolanejsi.


Mam firewall. Puvodne tam byl Solaris 8, ted je tam FreeBSD 6 - RELEASE.
Bezi tam pouze ipfilter, squid, sendmail a bind.

Hlavni problem je nejspis ipfilter (ale teoreticky to muze byt zpusobeny i necim jinym).

Od startu toho stroje vse normalne funguje, ale postupne se vse jebe a sit zacina "blbnout" - projevuje se to zejmena network unrechable a pod. - v priloze je graf z smokepingu, jak vypada takovy bezny tyden naseho firewallu. nejdriv to proste jde, ale pak se to drbe az to uplne chcipne.

Dnes jsem cvicne zkousel restartnout ipfilter a ipnat. ipnat uz pro jistotu odmitl naskocit.

Kód:

---

May 10 06:52:33 phil sshd[92680]: error: connect_to **.**.**.** port 3389: Network is unreachable
May 10 06:52:33 phil sshd[92680]: error: connect_to **.**.**.** port 3389: failed.
May 10 09:22:42 phil named[404]: client **.**.**.**#1077: error sending response: network unreachable
May 10 09:28:52 phil last message repeated 8 times
May 10 09:28:56 phil su: marty to root on /dev/ttyp0
May 10 09:34:16 phil named[404]: client **.**.**.**#1077: error sending response: network unreachable

---

Tusim nekde nejaky problem v nastaveni ipfilteru nebo nekde v kernelu, ale tohle je na me ted nejak moc :( v bsd jsem fakt lama (viz kdysi otazka na squid) :)

Poradi nekdo?

Dik moc.

nejakym tcpdumpem jsi nezkousel sledovat, kde ty pakety mizej, popripade odkud se co vraci ?
mimochodem, muzes to zkusit predelat do pf ... je znacne chytrejsi, rekl bych ...

No, on tam neni malej traffic... muzu to zkusit, je to dost komplikovany.

Proc pf ?

mam takovy hloupy tuseni, ze s ipf byly nejaky problemy s licencema a melo snad bejt z fbsd6 dokonce vypusteny ...
pf je mnohem chytrejsi a vychytanejsi ... (i kdyz nekery featury jsou tam hezky zbytecny ... )

Hmmm... ale jasnej prinos (zejmena odstraneni mych potizi) asi nema... :(

Citace:

---

Původně odeslal Marty

Hmmm... ale jasnej prinos (zejmena odstraneni mych potizi) asi nema... :(

---

mam to chapat tak, zes to zkousel? stale nefunguje ? mas nejaky ty dumpy? jaks vubec prisel na to, ze je to ve firewallu ?

Kdyz ipfilter stopnu, tak vse lita jak divoky. A kdyz firewall restartuju, tak se vse taky vyrazne zlepsi (ale pak zacne postupne zhorsovat).

PF jsem nezkousel ... pokud by to bylo jiste reseni, urcite bych do toho sel.

dumpy nemam - budu na to muset udelat nejakej rozumnej filtr, protoze jak jsem rekl, je tam dost trafficu.

Citace:

---

Původně odeslal Marty

Kdyz ipfilter stopnu, tak vse lita jak divoky. A kdyz firewall restartuju, tak se vse taky vyrazne zlepsi (ale pak zacne postupne zhorsovat).

PF jsem nezkousel ... pokud by to bylo jiste reseni, urcite bych do toho sel.

dumpy nemam - budu na to muset udelat nejakej rozumnej filtr, protoze jak jsem rekl, je tam dost trafficu.

---

Nekde v kernelu si posun limity pro pocet aktivnich spojeni, to by mohlo pomoct. A jeste si mohl napsat jak to je zapojeny, nemas tam nahodou NAT pro tisic lidi s P2P klientama?

Citace:

---

Původně odeslal hwsoft

Nekde v kernelu si posun limity pro pocet aktivnich spojeni, to by mohlo pomoct. A jeste si mohl napsat jak to je zapojeny, nemas tam nahodou NAT pro tisic lidi s P2P klientama?

---

ee. je tam nat pro cca 20 klientu do privatniho rozsahu a druhej nat pro cca. 70 klientu do verejnyho rozsahu.

...ostatne P2P tam mozna nekdo pouziva... dik za tip - tusi nekdo kde presne v kernelu limit poctu aktivnich spojeni je?

mel bys tam mit nejkej tool, kterej ti vypise aktivni/otevreny konexe. podle toho chovani to vidim tak, ze ti zustavaj otevreny uz davno neaktivni konexe a ta tabulka se plni az se naplni a pak uz neni jak otevrit dalsi. Nektery prasecky napsany SW po sobe konexe neuzaviraj a je to treba po nejakym timeoutu delat natvrdo. To samo plati pro NAT/maskaradu, klasicky smerovani tenhle problem nema.

Bliz ti neporadim, alebrz BSD neznam.

Kód:

---

sysctl -a  | grep ipf

---

Citace:

---

Původně odeslal Marty

ee. je tam nat pro cca 20 klientu do privatniho rozsahu a druhej nat pro cca. 70 klientu do verejnyho rozsahu.

---

No rozumim spravne ze mas NAT1:N pro 20 lidi a NAT 1:1 pro 70 dalsich? To byz zas takovej problem bejt nemusel, ale uz mi nejakej cerv na M$ shitech takhle zlobil. Dal jsem okamzity reject na vsechno co slo na M$ sdileni, porty 139,145. Nedavej tam DROP, protoze jak to dlouho timeoutuje, tak jsi tam kde ted.

Citace:

---

Původně odeslal Fox!MURDER

Kód:

---

sysctl -a  | grep ipf

---

---

Kód:

---

phil# sysctl -a  | grep ipf
net.inet.ipf.fr_minttl: 4
net.inet.ipf.fr_chksrc: 0
net.inet.ipf.fr_defaultauthage: 600
net.inet.ipf.fr_authused: 0
net.inet.ipf.fr_authsize: 32
net.inet.ipf.ipf_hostmap_sz: 2047
net.inet.ipf.ipf_rdrrules_sz: 127
net.inet.ipf.ipf_natrules_sz: 127
net.inet.ipf.ipf_nattable_sz: 2047
net.inet.ipf.fr_statemax: 4013
net.inet.ipf.fr_statesize: 5737
net.inet.ipf.fr_running: 1
net.inet.ipf.fr_ipfrttl: 120
net.inet.ipf.fr_defnatage: 1200
net.inet.ipf.fr_icmptimeout: 120
net.inet.ipf.fr_udpacktimeout: 24
net.inet.ipf.fr_udptimeout: 240
net.inet.ipf.fr_tcpclosed: 120
net.inet.ipf.fr_tcptimeout: 480
net.inet.ipf.fr_tcplastack: 480
net.inet.ipf.fr_tcpclosewait: 480
net.inet.ipf.fr_tcphalfclosed: 14400
net.inet.ipf.fr_tcpidletimeout: 864000
net.inet.ipf.fr_active: 0
net.inet.ipf.fr_pass: 134217730
net.inet.ipf.fr_flags: 0
net.link.ether.ipfw: 0

---

... na ten zbytek se podivam.

Zdar vsem.

Dekuji za dosavadni rady, bohuzel system stale obcas zlobi.

Updatoval jsem kernel a ipfilter.

FreeBSD phil.*.* 6.0-RELEASE FreeBSD 6.0-RELEASE #1: Sun May 7 13:19:34 CEST 2006 root@phil.*.*:/usr/src/sys/i386/compile/PHIL i386

Od te doby to docela dobre bezelo ale nedavno se to zase dodrbalo.

Kód:

---

net.inet.ipf.fr_minttl: 4
net.inet.ipf.fr_chksrc: 0
net.inet.ipf.fr_defaultauthage: 600
net.inet.ipf.fr_authused: 0
net.inet.ipf.fr_authsize: 32
net.inet.ipf.ipf_hostmap_sz: 2047
net.inet.ipf.ipf_rdrrules_sz: 127
net.inet.ipf.ipf_natrules_sz: 127
net.inet.ipf.ipf_nattable_sz: 2047
net.inet.ipf.fr_statemax: 4013
net.inet.ipf.fr_statesize: 5737
net.inet.ipf.fr_running: 1
net.inet.ipf.fr_ipfrttl: 120
net.inet.ipf.fr_defnatage: 1200
net.inet.ipf.fr_icmptimeout: 120
net.inet.ipf.fr_udpacktimeout: 24
net.inet.ipf.fr_udptimeout: 240
net.inet.ipf.fr_tcpclosed: 120
net.inet.ipf.fr_tcptimeout: 480
net.inet.ipf.fr_tcplastack: 480
net.inet.ipf.fr_tcpclosewait: 480
net.inet.ipf.fr_tcphalfclosed: 14400
net.inet.ipf.fr_tcpidletimeout: 864000
net.inet.ipf.fr_active: 0
net.inet.ipf.fr_pass: 134217730
net.inet.ipf.fr_flags: 0
net.link.ether.ipfw: 0

---

Vyresil to restart serveru, ale predpokladam, ze se to zas dodrbe.

Nekdo nejake dalsi tipy?

zkus ty vypisy ze sysctl porovnat mezi stavem 'vporadku' a stavem 'nefunguje'
a jeste bych totez zkusil s vypisem ipfstat -s a ipfstat -f

Dik za tip. S dovolenim si to ulozim tady.

Kód:

---

gw% ssh phil
Enter passphrase for key '/home/marty/.ssh/id_rsa':
Password:
Last login: Thu Aug 24 11:43:59 2006 from gw.myslenka.net
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.  All rights reserved.

FreeBSD 6.0-RELEASE (PHIL) #1: Sun May  7 13:19:34 CEST 2006

bash-2.05b$ su
Password:
phil# ipfstat -f
IP fragment states:
        22508 new
        22508 expired
        22516 hits
        0 retrans
        0 too short
        0 no memory
        0 already exist
        0 inuse

phil# ipfstat -s
IP states added:
        1233008 TCP
        1044241 UDP
        60153 ICMP
        116203739 hits
        2743693 misses
        8930 maximum
        0 no memory
        0 max bucket
        8930 maximum
        0 no memory
        1851 bkts in use
        3143 active
        0 expired
        615025 closed
State logging enabled

State table bucket statistics:
        1851 in use
        32.26% bucket usage
        0 minimal length
        7 maximal length
        1.398 average length

phil#

---

To by me zajimalo, na co prijdete :) Kdyz jsem si s tim hral doma (jako router), tak se obcas taky objevily problemy, obcas se neco ztratilo, obcas prestal jit internet, napadnou souvislost jsem nasel s pustenym utorrentem .. Takze bych si taky vsadil na vyse uvedenou domnenku ohledne otevrenych spojeni :)

Tak, uz se to zas zacina dojebavat - packetloss vylezl zas nad unosnou uroven.

tady vypisy z ipfstat - jdu to nastudovat.

Kód:

---

phil# ipfstat -f
IP fragment states:
        55558 new
        55558 expired
        55616 hits
        0 retrans
        0 too short
        0 no memory
        0 already exist
        0 inuse

phil# ipfstat -s
IP states added:
        2253327 TCP
        2373536 UDP
        153149 ICMP
        329237950 hits
        7573706 misses
        1715004 maximum
        0 no memory
        0 max bucket
        1715004 maximum
        0 no memory
        1862 bkts in use
        4013 active
        0 expired
        1364435 closed
State logging enabled

State table bucket statistics:
        1862 in use
        32.46% bucket usage
        0 minimal length
        6 maximal length
        1.395 average length

---

tohle mi pripada celkem v poradku ... nemuze bejt problem treba v driveru sitovky? zkousels to nejak?

Ovladac sitovky jsem nejak nestudoval.
Jsou tam nejaky 3Comy:

Kód:

---

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet6 fe80::290:27ff:fe84:40e2%fxp0 prefixlen 64 scopeid 0x1
        inet xxx netmask 0xfffffff8 broadcast xxx
        ether 00:90:27:84:40:e2
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet6 fe80::2d0:b7ff:fea9:8733%fxp1 prefixlen 64 scopeid 0x2
        inet xxx netmask 0xffffffc0 broadcast xxx
        ether 00:d0:b7:a9:87:33
        media: Ethernet 100baseTX <full-duplex>
        status: active
fxp2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet6 fe80::2aa:ff:fead:2dc1%fxp2 prefixlen 64 scopeid 0x3
        inet 10.9.0.1 netmask 0xffffff00 broadcast 10.9.0.255
        ether 00:aa:00:ad:2d:c1
        media: Ethernet 100baseTX <full-duplex>
        status: active

---

fxp0 je externi, zapojena do malyho switchiku a odtamtud do routeru ISP.
fxp1 je interni s verejnou adresou, za ni je jedna sit.
fxp2 je interni s NATem do privatniho rozsahu do druhe site.

Vsechno jsou 3Comy, PL se projevuje pri monitoringu ze site 1 do site 2 i do internetu.
Jedina externi sitovka ma nastaveno autodetect na LS a duplex, protoze je v nemanagovatelnym switchi.

Co se tyce sitovek, tak muzu zkusit vymenit, ale IMHO hardwarove budou v pohode.

Jak zjistit nejake info z toho ovladace?

Citace:

---

Původně odeslal Marty

Ovladac sitovky jsem nejak nestudoval.
Jsou tam nejaky 3Comy:

Kód:

---

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet6 fe80::290:27ff:fe84:40e2%fxp0 prefixlen 64 scopeid 0x1
        inet xxx netmask 0xfffffff8 broadcast xxx
        ether 00:90:27:84:40:e2
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet6 fe80::2d0:b7ff:fea9:8733%fxp1 prefixlen 64 scopeid 0x2
        inet xxx netmask 0xffffffc0 broadcast xxx
        ether 00:d0:b7:a9:87:33
        media: Ethernet 100baseTX <full-duplex>
        status: active
fxp2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet6 fe80::2aa:ff:fead:2dc1%fxp2 prefixlen 64 scopeid 0x3
        inet 10.9.0.1 netmask 0xffffff00 broadcast 10.9.0.255
        ether 00:aa:00:ad:2d:c1
        media: Ethernet 100baseTX <full-duplex>
        status: active

---

fxp0 je externi, zapojena do malyho switchiku a odtamtud do routeru ISP.
fxp1 je interni s verejnou adresou, za ni je jedna sit.
fxp2 je interni s NATem do privatniho rozsahu do druhe site.

Vsechno jsou 3Comy, PL se projevuje pri monitoringu ze site 1 do site 2 i do internetu.
Jedina externi sitovka ma nastaveno autodetect na LS a duplex, protoze je v nemanagovatelnym switchi.

Co se tyce sitovek, tak muzu zkusit vymenit, ale IMHO hardwarove budou v pohode.

Jak zjistit nejake info z toho ovladace?

---

3com?

Kód:

---

fxp - Intel EtherExpress Pro/100B ethernet device driver

---

jen tak cvicne muzes zkusit ifconfig fxp? link0
nepredpokladam, ze by to melo nejakej efekt, ale cvicne

jo a btw. nejaky vypojeni,zapojeni kabelu tomu nepomuze. unload reload firewallu taky ne. jediny co opravdu zabira je restart. je to tak ?

Jo, sorry, 3comy mam na testovacim firewallu.

Kód:

---

fxp0: <Intel 82559 Pro/100 Ethernet> port 0x2000-0x203f mem 0xf4300000-0xf4300fff,0xf4000000-0xf40fffff irq 17 at device 13.0 on pci0
miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:90:27:84:40:e2
fxp1: <Intel 82559 Pro/100 Ethernet> port 0x2040-0x207f mem 0xf4301000-0xf4301fff,0xf4100000-0xf41fffff irq 21 at device 14.0 on pci0
miibus1: <MII bus> on fxp1
inphy1: <i82555 10/100 media interface> on miibus1
inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp1: Ethernet address: 00:d0:b7:a9:87:33
fxp2: <Intel 82557 Pro/100 Ethernet> port 0x2080-0x209f mem 0xf4305000-0xf4305fff,0xf4200000-0xf42fffff irq 16 at device 16.0 on pci0
miibus2: <MII bus> on fxp2
nsphy0: <DP83840 10/100 media interface> on miibus2
nsphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp2: Ethernet address: 00:aa:00:ad:2d:c1

---

Nemohlo by se stat, ze se ovladac pro Intel natahne k nejakymu jinymu zarizeni? 2 Intely tam byly, ale to treti se mi nejak nezda. Checknu to.. ale az nekdy zitra.

Jinak co dela ten ifconfig link0? nic to neudelalo...


EDIT
jo, vyresi to restart serveru, reload ani restart firewallu ne. vytazeni/zatazeni kabelu netestovano, jsem vetsinou dost mimo. Ale mozna se tam dnes zastavim to zkusit.

Citace:

---

Původně odeslal Marty

Jo, sorry, 3comy mam na testovacim firewallu.

Kód:

---

fxp0: <Intel 82559 Pro/100 Ethernet> port 0x2000-0x203f mem 0xf4300000-0xf4300fff,0xf4000000-0xf40fffff irq 17 at device 13.0 on pci0
miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:90:27:84:40:e2
fxp1: <Intel 82559 Pro/100 Ethernet> port 0x2040-0x207f mem 0xf4301000-0xf4301fff,0xf4100000-0xf41fffff irq 21 at device 14.0 on pci0
miibus1: <MII bus> on fxp1
inphy1: <i82555 10/100 media interface> on miibus1
inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp1: Ethernet address: 00:d0:b7:a9:87:33
fxp2: <Intel 82557 Pro/100 Ethernet> port 0x2080-0x209f mem 0xf4305000-0xf4305fff,0xf4200000-0xf42fffff irq 16 at device 16.0 on pci0
miibus2: <MII bus> on fxp2
nsphy0: <DP83840 10/100 media interface> on miibus2
nsphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp2: Ethernet address: 00:aa:00:ad:2d:c1

---

Nemohlo by se stat, ze se ovladac pro Intel natahne k nejakymu jinymu zarizeni? 2 Intely tam byly, ale to treti se mi nejak nezda. Checknu to.. ale az nekdy zitra.

Jinak co dela ten ifconfig link0? nic to neudelalo...


EDIT
jo, vyresi to restart serveru, reload ani restart firewallu ne. vytazeni/zatazeni kabelu netestovano, jsem vetsinou dost mimo. Ale mozna se tam dnes zastavim to zkusit.

---

link0 naleje do sitovky custom firmware ... (mimo jine by tam mel bejt tusim interrupt offloading)
co se ti u ty treti nezda?

Uz nic, overil jsem to - vsechno jsou to intely, takze OK.

A ten link0 bohuzel beze zmeny.

net.inet.ipf.fr_tcpidletimeout: 864000

zmensi to, ta hodnota = nezavreny TCP spojeni ti vytimeoutuje az po 10 dnech.
Nerikam, ze je to tim, ale zkus to zmensit. Melo by se jit i podivat, kolik jich mas otevrenejch, ale nevim jak, neco jako netstat ?

Pokud to pomuze, tak hledej problem v nejaky zabugovany aplikaci.

Zabugovanou aplikaci budu hledat tezko, bezi tam kde co, od browseru az po p2p / dc, torrent...

na otevreny spojeni se mrknu.

Tak se to samo opravilo!!

Žádný restart, žádný čachrování s kabely, změny nastavení.
Ten firewall si dělá co chce. Nechápu..

EDIT. výpisy ipfstat

Kód:

---

phil# ipfstat -f
IP fragment states:
        72990 new
        72990 expired
        73064 hits
        0 retrans
        0 too short
        0 no memory
        0 already exist
        0 inuse

phil# ipfstat -s
IP states added:
        2644444 TCP
        3012634 UDP
        203007 ICMP
        674637929 hits
        10225163 misses
        2898609 maximum
        0 no memory
        0 max bucket
        2898609 maximum
        0 no memory
        1756 bkts in use
        3939 active
        0 expired
        1718773 closed
State logging enabled

State table bucket statistics:
        1756 in use
        30.61% bucket usage
        0 minimal length
        6 maximal length
        1.378 average length

---

no nevim system kterej se "sam" opravuje ...
Moc bych tomu neveril. Je klido mozny ze to bylo zpusobeny nejakym externim vlivem, kterej aktualne neexistuje. Je tam moznej nejakej DOS ?

Tezko rict, imho ne, ta linka do internetu je cca. 20-30Mb optika... zahltit to by dalo docela praci.

To muze byt i zevnitr, ale takhle tezko rict, uvidis jak se to bude chovat dal, ale osobne mivam dycky takovej divnej pocit kdyz se neco opravi samo.

Mno tak problém se zdá být vyřešen...

sice se to nejdřív "opravilo samo" ale pak kolega ještě hrabal v pravidlech IPF a trochu tam přeházel pořadí. Nikdy bych nehledal problém tady, protože ty pravidla jsou tam ještě z dob, kdy tam bez problémů běžel Solaris a tohle se nedělo.
Zdá se, že to bylo tedy pořadím pravidel - prý tam nějaké z pravidel více na konci rušilo stav některého pravidla na začátku, což mělo za efekt padání spojení - dokonce v pravidelných intervalech. Projevovalo se to citlivě jen v některých případech..

Ještě to budu sledovat a podám info, pokud zjistím nějaké další souvislosti.

Citace:

---

Původně odeslal Marty

Mno tak problém se zdá být vyřešen...

sice se to nejdřív "opravilo samo" ale pak kolega ještě hrabal v pravidlech IPF a trochu tam přeházel pořadí. Nikdy bych nehledal problém tady, protože ty pravidla jsou tam ještě z dob, kdy tam bez problémů běžel Solaris a tohle se nedělo.
Zdá se, že to bylo tedy pořadím pravidel - prý tam nějaké z pravidel více na konci rušilo stav některého pravidla na začátku, což mělo za efekt padání spojení - dokonce v pravidelných intervalech. Projevovalo se to citlivě jen v některých případech..

Ještě to budu sledovat a podám info, pokud zjistím nějaké další souvislosti.

---

nemoh bys nejaky podrobnejsi info, co se s cim rusilo ?