***: mhoran3 has joined #arpnetworks
ChanServ sets mode: +o mhoran3
mhoran2 has quit IRC (Ping timeout: 260 seconds)
meingtsla has quit IRC (Ping timeout: 260 seconds)
meingtsla has joined #arpnetworks
first2know has joined #arpnetworks
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
heavysixer has quit IRC (Quit: heavysixer)
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
heavysixer has quit IRC (Quit: heavysixer)
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
heavysixer has quit IRC (Quit: heavysixer)
fink has joined #arpnetworks
heavysixer has joined #arpnetworks
ChanServ sets mode: +o heavysixer
heavysixer has quit IRC (Ping timeout: 245 seconds)
fink has quit IRC (Ping timeout: 246 seconds)
fink has joined #arpnetworks
HighJinx has quit IRC (Ping timeout: 256 seconds)
HighJinx has joined #arpnetworks
first2know has quit IRC (Ping timeout: 256 seconds)
knigma-m has joined #arpnetworks knigma-m: 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? robonerd: hm good question knigma-m: 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
and ping works
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
it also seems tcp port specific - so far only affecting port 22
SYNs to other TCP ports get through CaZe: Highly doubtful. knigma-m: doubtful perhaps; but something is blocking my SYNs and it's not the OS on the VM sfaict
this time it took 5 minutes for them to get through after a reboot
so essentially I have to wait 5-25 minutes after a reboot before I can reconnect
ideas welcome - if anyone can think of anything else that might cause this behaviour sdkmvx: knigma-m, why is your laptop constantly trying to connect while its off? knigma-m: just what my Windows ssh client does - keep retrying since it's configured to be a persistent connection
...never caused a problem before
means the ssh connection is re-established every time I switch networks or suspend/resume
I've no *evidence* that's triggering the issue; I just cannot think of another explanation sdkmvx: perhaps turning it off and seeing whether it still blocks connections after a reboot will give more information. knigma-m: ok - I'll do that now ;)
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? robonerd: seems to be. this would be good to know knigma-m: ...perhaps trying to protect against port scans or random IP searching robonerd: that is question 1. question 2 would be if your client supports reconnect throttling knigma-m: q2. No, sadly not. I guess it waits for a TCP connection timeout and once it gets that retries immediately.
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.
...so I spent ages assuming is was somethign screwed up on my laptop
perhaps it looks like a SYN flood, but it really shouldn't that that aggresive, Windows doesn't send that many SYNs. ant: knigma-m: there is some kind of filtering to prevent ssh brute force robonerd: seems quite aggressive if it's preventing persistent connection clients knigma-m: ok - thanks; I can live with that - just seems a little too sensitive robonerd: yes
i agree
any way we can have that throttled down in sensitivity somewhat? knigma-m: it's just one persistent client - so I guess only a SYN a second ant: ha, found it: http://irclogger.arpnetworks.com/irclogger_log_search/arpnetworks?search=ssh+syn&action=search&error=0 robonerd: it should be higher
like more than 60 in 1 minute, not 10 knigma-m: thanks - good - problem understood - that's kina crazy low though robonerd: no brute force will be effective at only 1 per second
brute force begins at 10+/sec imo ant: i have seen ssh brute force at much lower rates... knigma-m: running a quick test; a few successful ssh connections also trips the filter, so it's not resistricted to unsuccessful attempts
just "ssh x.y.z ls" a few times trips it ant: no it just counts syns knigma-m: but a relatively short break from SYNs seems to remove the filter; so my problem is that my ssh client never takes a break ant: to only count unsuccessful attempts the rate limiting would need to happen on the host not on some router in between knigma-m: yep - would require a stateful rule; ok well at least I know it's not my end that's broken - thanks for the input ant: err, host is ambigous. i mean the ssh server, i.e. the vps knigma-m: the "rule" only blocks SYNs, once existing TCP connections from the same IP aren't impacted ant: well, that would be very bad... robonerd: :) ant: like typing to fast and get disconnected... knigma-m: lol robonerd: :P
i need to make that a t shirt; "I type so fast my firewall's TCP throttle rate is exceeded" ***: knigma-m_ has joined #arpnetworks
knigma-m has quit IRC (Read error: Connection reset by peer)
knigma-m_ is now known as knigma-m
knigma-m_ has joined #arpnetworks
knigma-m has quit IRC (Read error: Connection reset by peer)
knigma-m_ is now known as knigma-m
fink has quit IRC (Quit: fink)
fink has joined #arpnetworks
fink has quit IRC (Quit: fink) up_the_irons2: that would indeed be a good tshirt brycec: oh hey it's another up_the_irons2 up_the_irons: migrating to latest weechat and bitlbee, so i have two servers runnin' at the moment
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 ;) brycec: 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..." up_the_irons: i tend to agree -: brycec was under the impression that there was absolutely no firewalling mnathani: Then there is the outbound UDP ratelimiting as well brycec: oh is there? any specific ports? brachiation: are you cheating on irssi?
poor irrsula... brycec: brachiation: up_the_irons has run weechat for as long as I can remember, and even longer according to the logs :p brachiation: i could have sworn it was irssi... i like irssi myself. brycec: I'm happy with irssi. I've tried weechat, and have no complaints really... I'm just entrenched in irssi nowadays brachiation: the default weechat theme reminds me of a circus. mike-burns: The /clown_act command is my favorite part, though the /lion_tamer bit is fun too. ***: first2know has joined #arpnetworks brachiation: i like how they gzip all those clowns in the carball. robonerd: brycec i agree, it should be explicit somewhere
docs! up_the_irons: brachiation: nah, i've been on weechat for as long as i can remember.. was in irssi before