On 24-02-17 09:00, Xen wrote:
> zephura schreef op 24-02-2017 8:15:
>> Maybe I don't get the point, but
>> For bad reasons, I've already have the same ssh connection during 3
>> days...
>> Ok that was through a vpn tunnel, but even I should allow ssh
>> connection in vuurmuur ...
>
> I just don't know what is causing it. Maybe it is a mechanic that
> packets get blocked because they end up in a wrong state in the
> firewall. There is also LXC container that has a bridge with an IP on
> the same interface (device) and the Linux kernel sometimes does weird
> stuff when you use a bridge in the wrong way. So I have to find out
> what's causing it but for that I first have to turn Vuurmuur off and see
> if I can reproduce the issue.
>
> The connection is not even over VPN.
>
> "tar -xvzf" or similar (the -v) is a very dangerous thing right now ;-).
> The tar process will hang if it cannot output all the data, the lines of
> text.
>
> Basically there is two things I can test:
>
> - bring down the LXC bridge
> - bring down Vuurmuur
>
> Either which could produce the solution but troubleshooting IPtable
> rules is not something you do in your spare time... while eating a
> pizza, so to say.
>
> I have now a script running on a relatively fresh connection (ssh) that
> will output "journalctl | cat" to the console every 6 seconds ;-) and
> records the date for it in a file. Once the connection clogs up, I will
> see the latest date. It is now 08:56 when I started it. Nothing happened
> thus far.
While at it maybe you can run (& keep running):
conntrack -E -p 6 --dport 22
(assuming the ssh ssns are on port 22)
It will show updates to how conntrack sees the ssh connections. It might
show nothing at first if there are no updates.
Example:
# conntrack -E -p 6 --dport 22
[NEW] tcp 6 120 SYN_SENT src=185.40.4.34 dst=192.168.178.254
sport=43242 dport=22 [UNREPLIED] src=192.168.0.123 dst=185.40.4.34
sport=22 dport=43242 mark=3
[UPDATE] tcp 6 60 SYN_RECV src=185.40.4.34 dst=192.168.178.254
sport=43242 dport=22 src=192.168.0.123 dst=185.40.4.34 sport=22
dport=43242 mark=3
[UPDATE] tcp 6 10 CLOSE src=185.40.4.34 dst=192.168.178.254
sport=43242 dport=22 src=192.168.0.123 dst=185.40.4.34 sport=22
dport=43242 mark=3
[DESTROY] tcp 6 src=185.40.4.34 dst=192.168.178.254 sport=43242
dport=22 packets=3 bytes=124 src=192.168.0.123 dst=185.40.4.34 sport=22
dport=43242 packets=1 bytes=44 mark=3
[NEW] tcp 6 120 SYN_SENT src=185.40.4.34 dst=192.168.178.254
sport=43242 dport=22 [UNREPLIED] src=192.168.0.123 dst=185.40.4.34
sport=22 dport=43242 mark=3
[UPDATE] tcp 6 60 SYN_RECV src=185.40.4.34 dst=192.168.178.254
sport=43242 dport=22 src=192.168.0.123 dst=185.40.4.34 sport=22
dport=43242 mark=3
[UPDATE] tcp 6 10 CLOSE src=185.40.4.34 dst=192.168.178.254
sport=43242 dport=22 src=192.168.0.123 dst=185.40.4.34 sport=22
dport=43242 mark=3
[DESTROY] tcp 6 src=185.40.4.34 dst=192.168.178.254 sport=43242
dport=22 packets=2 bytes=84 src=192.168.0.123 dst=185.40.4.34 sport=22
dport=43242 packets=1 bytes=44 mark=3
> It is on older connections that "tar -v" becomes very dangerous.
Side note: use something screen/tmux to avoid this. Regardless of the
issue you have that is a good idea in my opinion.
--
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Vuurmuur-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/vuurmuur-users
