2* tcp.closing looks very close to 1740 :8~) Just a wild guess. well, afaik the most of the skype traffic is running over udp and only parts over tcp ( except M$ changed this ), so not really helpful. i am not sure yet, which are sent over tcp.
Any IDS(Snort) running? if so, disable it and test without it. if not or if this doesn't help: i would monitor the traffic during a session and also the related states. this gives more exact hints on the possible error source than just guessing. netstat -nltup |grep -i skype # on the client if unix like for gathering IP(s) and Ports. tcpdump -nettttvvi $IFNAME host $client_hostname and port $aquired_port and port $aquired_port2 > $save_it_into_this_file # on the firewall during the session. replace the vars. https://doc.pfsense.org/index.php/Sniffers,_Packet_Capture if you like to save it to a file ( like in the example above), keep in mind: if you are using a Nanobsd-Install, you can get into trouble, if the filesize is to big for the RAM-Disks or you have to mount disk space manually. Further you must save the state-table periodically, so you can see when a state got dropped by the filter. this can get scripted a bit with the help of sleep you are only interested in the last minutes of the skype-session. either you take care of the timing or just put a script together with a sleep command at the beginning, which lets enough timespace. for easy going you can also setup a certain rule at the top of your LAN rules table for the selected host with logging enabled. if i remeber well, there is a copy of the output (pflog0) in /tmp or /var/log/pf.... Afterwards you can inspect the files and see what happened. = = = http://michael-schuh.net/ = = = Projektmanagement - IT-Consulting - Professional Services IT Postfach 10 21 52 66021 Saarbrücken phone: 0681/8319664 @: m i c h a e l . s c h u h @ g m a i l . c o m = = = Ust-ID: DE251072318 = = = 2014-06-16 23:09 GMT+02:00 Vick Khera <[email protected]>: > On Mon, Jun 16, 2014 at 5:05 PM, Michael Schuh <[email protected]> > wrote: > > pfctl -s timeouts > > tcp.first 120s > tcp.opening 30s > tcp.established 86400s > tcp.closing 900s > tcp.finwait 45s > tcp.closed 90s > tcp.tsdiff 30s > udp.first 60s > udp.single 30s > udp.multiple 60s > icmp.first 20s > icmp.error 10s > other.first 60s > other.single 30s > other.multiple 60s > frag 30s > interval 10s > adaptive.start 0 states > adaptive.end 0 states > src.track 0s > > Nothing looks to be in the same order as 29 minutes, which would be > 1740 seconds.. The closest is tcp.closing which is half that. > _______________________________________________ > List mailing list > [email protected] > https://lists.pfsense.org/mailman/listinfo/list >
_______________________________________________ List mailing list [email protected] https://lists.pfsense.org/mailman/listinfo/list
