[00:45] *** fink has quit IRC (Quit: fink) [02:45] *** mhoran3 has joined #arpnetworks [02:45] *** ChanServ sets mode: +o mhoran3 [02:45] *** mhoran2 has quit IRC (Ping timeout: 260 seconds) [02:45] *** meingtsla has quit IRC (Ping timeout: 260 seconds) [02:50] *** meingtsla has joined #arpnetworks [03:10] *** first2know has joined #arpnetworks [05:46] *** heavysixer has joined #arpnetworks [05:46] *** ChanServ sets mode: +o heavysixer [06:04] *** heavysixer has quit IRC (Quit: heavysixer) [06:30] *** heavysixer has joined #arpnetworks [06:30] *** ChanServ sets mode: +o heavysixer [07:01] *** heavysixer has quit IRC (Quit: heavysixer) [07:13] *** heavysixer has joined #arpnetworks [07:13] *** ChanServ sets mode: +o heavysixer [07:25] *** heavysixer has quit IRC (Quit: heavysixer) [08:06] *** fink has joined #arpnetworks [08:25] *** heavysixer has joined #arpnetworks [08:25] *** ChanServ sets mode: +o heavysixer [08:30] *** heavysixer has quit IRC (Ping timeout: 245 seconds) [09:47] *** fink has quit IRC (Ping timeout: 246 seconds) [09:51] *** fink has joined #arpnetworks [11:40] *** HighJinx has quit IRC (Ping timeout: 256 seconds) [11:45] *** HighJinx has joined #arpnetworks [12:37] *** first2know has quit IRC (Ping timeout: 256 seconds) [13:53] *** knigma-m has joined #arpnetworks [13:55] Hi - been running a VM for a while and everytime I reboot it I find I cannot connect to it again from my laptop for a while. Playing with tcpdump it looks like my outgoing TCP SYNs are not making it to my VM after a reboot. Is there some sort of firewall between my VM and the Internet that could be causing a problem? [14:00] hm good question [14:01] essentally after a reboot ssh access via TCP port 22 seems down from my laptop for ~25 minutes, but from other IPs it's ok [14:01] and ping works [14:02] my laptop ssh client will have been trying to reconnect every few seconds during the reboot; I wonder if it's tickling some protection I'm not aware of [14:06] it also seems tcp port specific - so far only affecting port 22 [14:06] SYNs to other TCP ports get through [14:06] Highly doubtful. [14:07] doubtful perhaps; but something is blocking my SYNs and it's not the OS on the VM sfaict [14:08] this time it took 5 minutes for them to get through after a reboot [14:09] so essentially I have to wait 5-25 minutes after a reboot before I can reconnect [14:09] ideas welcome - if anyone can think of anything else that might cause this behaviour [14:09] knigma-m, why is your laptop constantly trying to connect while its off? [14:10] just what my Windows ssh client does - keep retrying since it's configured to be a persistent connection [14:10] ...never caused a problem before [14:11] means the ssh connection is re-established every time I switch networks or suspend/resume [14:11] I've no *evidence* that's triggering the issue; I just cannot think of another explanation [14:12] perhaps turning it off and seeing whether it still blocks connections after a reboot will give more information. [14:12] ok - I'll do that now ;) [14:15] yes - was able to re-connect first time if I allowed a reboot to complete first. Can anyone confirm that there *is* some sort of firewall in front of my VM that would explain this behaviour? [14:15] seems to be. this would be good to know [14:15] ...perhaps trying to protect against port scans or random IP searching [14:16] that is question 1. question 2 would be if your client supports reconnect throttling [14:16] q2. No, sadly not. I guess it waits for a TCP connection timeout and once it gets that retries immediately. [14:17] I'm fine with it if I can explain it - just I haven't seen any documentation that explains there's a firewall in front of my VM. [14:17] ...so I spent ages assuming is was somethign screwed up on my laptop [14:19] perhaps it looks like a SYN flood, but it really shouldn't that that aggresive, Windows doesn't send that many SYNs. [14:25] knigma-m: there is some kind of filtering to prevent ssh brute force [14:25] seems quite aggressive if it's preventing persistent connection clients [14:25] ok - thanks; I can live with that - just seems a little too sensitive [14:25] yes [14:25] i agree [14:25] any way we can have that throttled down in sensitivity somewhat? [14:26] it's just one persistent client - so I guess only a SYN a second [14:33] ha, found it: http://irclogger.arpnetworks.com/irclogger_log_search/arpnetworks?search=ssh+syn&action=search&error=0 [14:34] it should be higher [14:34] like more than 60 in 1 minute, not 10 [14:34] thanks - good - problem understood - that's kina crazy low though [14:34] no brute force will be effective at only 1 per second [14:35] brute force begins at 10+/sec imo [14:37] i have seen ssh brute force at much lower rates... [14:37] running a quick test; a few successful ssh connections also trips the filter, so it's not resistricted to unsuccessful attempts [14:38] just "ssh x.y.z ls" a few times trips it [14:38] no it just counts syns [14:39] but a relatively short break from SYNs seems to remove the filter; so my problem is that my ssh client never takes a break [14:39] to only count unsuccessful attempts the rate limiting would need to happen on the host not on some router in between [14:40] yep - would require a stateful rule; ok well at least I know it's not my end that's broken - thanks for the input [14:40] err, host is ambigous. i mean the ssh server, i.e. the vps [14:42] the "rule" only blocks SYNs, once existing TCP connections from the same IP aren't impacted [14:43] well, that would be very bad... [14:43] :) [14:43] like typing to fast and get disconnected... [14:44] lol [14:44] :P [14:45] i need to make that a t shirt; "I type so fast my firewall's TCP throttle rate is exceeded" [14:47] *** knigma-m_ has joined #arpnetworks [14:48] *** knigma-m has quit IRC (Read error: Connection reset by peer) [14:49] *** knigma-m_ is now known as knigma-m [15:09] *** knigma-m_ has joined #arpnetworks [15:09] *** knigma-m has quit IRC (Read error: Connection reset by peer) [15:44] *** knigma-m_ is now known as knigma-m [19:08] *** fink has quit IRC (Quit: fink) [19:20] *** fink has joined #arpnetworks [21:26] *** fink has quit IRC (Quit: fink) [22:58] that would indeed be a good tshirt [23:18] oh hey it's another up_the_irons2 [23:19] migrating to latest weechat and bitlbee, so i have two servers runnin' at the moment [23:20] anyone have a way to get better 256 color support in weechat 4? i mean, i have it doing 256 colors, but *by default*, it only defines like 20 of them... you can define others, but i'd rather not have to do it all on my own ;) [23:20] up_the_irons/up_the_irons2: After the earlier discussion, I went looking through the FAQ but there's no mention that ARP has any firewalling. I think this really ought to be published, eg "we don't firewall anything except..." [23:20] i tend to agree [23:20] * brycec was under the impression that there was absolutely no firewalling [23:29] Then there is the outbound UDP ratelimiting as well [23:30] oh is there? any specific ports? [23:34] are you cheating on irssi? [23:35] poor irrsula... [23:36] brachiation: up_the_irons has run weechat for as long as I can remember, and even longer according to the logs :p [23:37] i could have sworn it was irssi... i like irssi myself. [23:37] I'm happy with irssi. I've tried weechat, and have no complaints really... I'm just entrenched in irssi nowadays [23:38] the default weechat theme reminds me of a circus. [23:39] The /clown_act command is my favorite part, though the /lion_tamer bit is fun too. [23:41] *** first2know has joined #arpnetworks [23:42] i like how they gzip all those clowns in the carball. [23:43] brycec i agree, it should be explicit somewhere [23:43] docs! [23:54] brachiation: nah, i've been on weechat for as long as i can remember.. was in irssi before