:strip_icc():strip_exif()/u/19746/firewall.jpg?f=community)
Relevante systeem informatie:
OS: FreeBSD 4.7
IP Filter: v3.4.29 (gecompileerd met default block optie)
Relevante ipf rules (ep0 = external interface, DHCP):
(dit is natuurlijk niet alles maar de rest doet hier weinig ter zake lijkt me)
Ik gebruik dus keep-state om connecties terug binnen te laten.
Ipfirewall support is niet meegecompileerd
Er wordt ook geNAT met ipnat
Het probleem:
Voor de 3de maal (in 3 weken tijd) kon ik plots op mijn workstation geen connecties naar buiten meer maken.
Een eerste onderzoek wees erop dat de dns faalde.
Ook op m'n router zelf lukte geen dns resolving meer.
Ik dacht meteen aan m'n firewall omdat ik iets dergelijk al eens meegemaakt had.
Poging tot oplossing/diagnose:
Even wat meer logging aangezet en ik zag dit:
Firewall log :
Hier is erg duidelijk te zien dat de statefull inspectie faalt.
Dan heb ik een rule bijgemaakt om de dns terug naar binnen te laten en daarna TCP getest.
Hierbij doet zich hetzelfde voor:
Het is uit met de keep-state pret dus
De vraag is natuurlijk waarom
M'n eerste gedachte was dat de state tabel volzat.
Maar flushen (-FA -Fs) loste niets op.
Ook met ipfstat -t zag ik maar dat er maar 1 state bijgehouden was.
ipfstat zonder argumenten gaf:
De packet state(out) bleef op kept 4701 terwijl de lost alsmaar omhoog ging.
In de andere log files vond ik niets relevant wat iets hiermee te zien zou hebben.
Het probleem is niet reproduceerbaar en doet zich random voor.
Een reboot lost het probleem op maar daar heb ik weinig aan
Extra informatiebronnen:
Weinig relevants op GoT gevonden.
Via wat gezoek op google vond ik wel dergelijke dingen:
http://home.earthlink.net/~jaymzh666/ipf/IPFprob.html#12
Maar die gaven altijd volle state tables aan als oorzaak.
Dat lijkt me niet het geval te zijn aangezien ik met ipfstat -t maar 1 state zag en een flush niets oploste.
Als iemand dit probleem herkent of misschien wat licht kan laten schijnen op dit duister probleem, dan hoor ik dit graag
OS: FreeBSD 4.7
IP Filter: v3.4.29 (gecompileerd met default block optie)
Relevante ipf rules (ep0 = external interface, DHCP):
code:
1
2
3
4
5
6
| @1 pass out quick on ep0 proto tcp from any to any flags S keep state @2 pass out quick on ep0 proto udp from any to any keep state @3 pass out quick on ep0 proto icmp from any to any keep state @4 block out quick on ep0 all @21 block in log quick on ep0 all |
(dit is natuurlijk niet alles maar de rest doet hier weinig ter zake lijkt me)
Ik gebruik dus keep-state om connecties terug binnen te laten.
Ipfirewall support is niet meegecompileerd
Er wordt ook geNAT met ipnat
Het probleem:
Voor de 3de maal (in 3 weken tijd) kon ik plots op mijn workstation geen connecties naar buiten meer maken.
Een eerste onderzoek wees erop dat de dns faalde.
Ook op m'n router zelf lukte geen dns resolving meer.
Ik dacht meteen aan m'n firewall omdat ik iets dergelijk al eens meegemaakt had.
Poging tot oplossing/diagnose:
Even wat meer logging aangezet en ik zag dit:
Firewall log :
code:
1
2
3
4
5
| UDP (dns) Nov 11 12:47:07 banshee ipmon[64]: 12:47:07.013784 ep0 @0:2 p 213.118.137.204,1024 -> 195.130.131.5,53 PR udp len 20 76 K-S OUT Nov 11 12:47:07 banshee ipmon[64]: 12:47:07.121443 ep0 @0:21 b 195.130.131.5,53 -> 213.118.137.204,1024 PR udp len 20 139 IN |
Hier is erg duidelijk te zien dat de statefull inspectie faalt.
Dan heb ik een rule bijgemaakt om de dns terug naar binnen te laten en daarna TCP getest.
Hierbij doet zich hetzelfde voor:
code:
1
2
3
4
5
6
7
8
| TCP Nov 11 13:11:18 banshee ipmon[64]: 13:11:18.304108 ep0 @0:1 p \ 213.118.137.204,4156 -> 213.224.83.182,8080 PR tcp len 20 44 \ -S 244739 480 0 65535 K-S OUT Nov 11 13:11:18 banshee ipmon[64]: 13:11:18.420558 ep0 @0:22 b \ 213.224.83.182,8080 -> 213.118.137.204,4156 PR tcp len 20 60 \ -AS 496688611 244739481 8760 IN |
Het is uit met de keep-state pret dus
De vraag is natuurlijk waarom
M'n eerste gedachte was dat de state tabel volzat.
Maar flushen (-FA -Fs) loste niets op.
Ook met ipfstat -t zag ik maar dat er maar 1 state bijgehouden was.
ipfstat zonder argumenten gaf:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| IPv6 packets: in 6 out 361
input packets: blocked 892 passed 103782 \
nomatch 22 counted 0 short 0
output packets: blocked 375 passed 104132 \
nomatch 151 counted 0 short 0
input packets logged: blocked 736 passed 0
output packets logged: blocked 0 passed 354
packets logged: input 0 output 0
log failures: input 0 output 0
fragment state(in): kept 0 lost 0
fragment state(out): kept 0 lost 0
packet state(in): kept 0 lost 0
packet state(out): kept 4701 lost 597 <--------| *
ICMP replies: 0 TCP RSTs sent: 12
Invalid source(in): 0
Result cache hits(in): 9202 (out): 11824
IN Pullups succeeded: 0 failed: 0
OUT Pullups succeeded: 0 failed: 0
Fastroute successes: 12 failures: 0
TCP cksum fails(in): 0 (out): 0
Packet log flags set: (0)
none |
De packet state(out) bleef op kept 4701 terwijl de lost alsmaar omhoog ging.
In de andere log files vond ik niets relevant wat iets hiermee te zien zou hebben.
Het probleem is niet reproduceerbaar en doet zich random voor.
Een reboot lost het probleem op maar daar heb ik weinig aan
Extra informatiebronnen:
Weinig relevants op GoT gevonden.
Via wat gezoek op google vond ik wel dergelijke dingen:
http://home.earthlink.net/~jaymzh666/ipf/IPFprob.html#12
Maar die gaven altijd volle state tables aan als oorzaak.
Dat lijkt me niet het geval te zijn aangezien ik met ipfstat -t maar 1 state zag en een flush niets oploste.
Als iemand dit probleem herkent of misschien wat licht kan laten schijnen op dit duister probleem, dan hoor ik dit graag
:strip_icc():strip_exif()/u/63314/freebsd.jpg?f=community)
en dat is niet opgevallen omdat ik gisteren ook via wat kernel vars de default block had uitgezet 
