Connection requests hang with SYN_SENT, after a few tries
We moved offices, and setup the LAN/WAN infrastructure at the new place.
When I initiate SSH connections to my server (which is in the cloud, not the LAN), it works OK for the first 3 or 4 requests at short intervals (like 4 calls within 5 secs), further connections hang in SYN_SENT status. Later requests all hang with SYN_SENT until what looks like a timeout. After that it will work again for a few times.
No changes were made to the server and different local clients behave this way. So I guess the difference lies in the IT infrastructure, not the two end-points.
What possible explanations are there for this behavior? Where should I look for a fix?
We use a Zyxel ZyWall firewall which we had to reset - does this have some filter which could explain this behavior?
networking ssh
asked Mar 6 '14 at 16:07
PhilippPhilipp
15618
add a comment |
We moved offices, and setup the LAN/WAN infrastructure at the new place.
When I initiate SSH connections to my server (which is in the cloud, not the LAN), it works OK for the first 3 or 4 requests at short intervals (like 4 calls within 5 secs), further connections hang in SYN_SENT status. Later requests all hang with SYN_SENT until what looks like a timeout. After that it will work again for a few times.
No changes were made to the server and different local clients behave this way. So I guess the difference lies in the IT infrastructure, not the two end-points.
What possible explanations are there for this behavior? Where should I look for a fix?
We use a Zyxel ZyWall firewall which we had to reset - does this have some filter which could explain this behavior?
networking ssh
asked Mar 6 '14 at 16:07
PhilippPhilipp
15618
add a comment |
We moved offices, and setup the LAN/WAN infrastructure at the new place.
When I initiate SSH connections to my server (which is in the cloud, not the LAN), it works OK for the first 3 or 4 requests at short intervals (like 4 calls within 5 secs), further connections hang in SYN_SENT status. Later requests all hang with SYN_SENT until what looks like a timeout. After that it will work again for a few times.
No changes were made to the server and different local clients behave this way. So I guess the difference lies in the IT infrastructure, not the two end-points.
What possible explanations are there for this behavior? Where should I look for a fix?
We use a Zyxel ZyWall firewall which we had to reset - does this have some filter which could explain this behavior?
networking ssh
asked Mar 6 '14 at 16:07
PhilippPhilipp
15618
We moved offices, and setup the LAN/WAN infrastructure at the new place.
When I initiate SSH connections to my server (which is in the cloud, not the LAN), it works OK for the first 3 or 4 requests at short intervals (like 4 calls within 5 secs), further connections hang in SYN_SENT status. Later requests all hang with SYN_SENT until what looks like a timeout. After that it will work again for a few times.
No changes were made to the server and different local clients behave this way. So I guess the difference lies in the IT infrastructure, not the two end-points.
What possible explanations are there for this behavior? Where should I look for a fix?
We use a Zyxel ZyWall firewall which we had to reset - does this have some filter which could explain this behavior?
networking ssh
networking ssh
asked Mar 6 '14 at 16:07
PhilippPhilipp
15618
asked Mar 6 '14 at 16:07
PhilippPhilipp
15618
asked Mar 6 '14 at 16:07
PhilippPhilipp
15618
asked Mar 6 '14 at 16:07
PhilippPhilipp
15618
asked Mar 6 '14 at 16:07
PhilippPhilipp
15618
15618
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The iptables rules on the server had a an "anti ssh bruteforce" rule chain which uses the "recent" module to drop connections after 4 attempts were made within 1 minute.
This rule had an exception in the INPUT chain, to allow all ssh from our face IP. As we moved, the face IP changed, and the rule had to be adapted. For reference, this is how I did this
List all iptables rules
# iptables -L --line-numbers
Notice the accept rule in the INPUT chain, which was set to accept all ssh connections from our (previous) face IP address and the anti bruteforce rule which drops ssh connections after several attempts in the SSH_CHECK chain:
Chain INPUT (policy ACCEPT)
num target prot opt source destination
...
14 ACCEPT tcp -- old.myISP.com anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num target prot opt source destination
...
3 DROP all -- anywhere anywhere recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source
Editing the rules in /etc/iptables.rules
Change
-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT
to
-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT
where 111.222.33.44 is the new face IP.
And read in the adapted rules:
# iptables-restore < /etc/iptables.rules
answered Mar 17 '14 at 16:06
PhilippPhilipp
15618
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f725561%2fconnection-requests-hang-with-syn-sent-after-a-few-tries%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The iptables rules on the server had a an "anti ssh bruteforce" rule chain which uses the "recent" module to drop connections after 4 attempts were made within 1 minute.
This rule had an exception in the INPUT chain, to allow all ssh from our face IP. As we moved, the face IP changed, and the rule had to be adapted. For reference, this is how I did this
List all iptables rules
# iptables -L --line-numbers
Notice the accept rule in the INPUT chain, which was set to accept all ssh connections from our (previous) face IP address and the anti bruteforce rule which drops ssh connections after several attempts in the SSH_CHECK chain:
Chain INPUT (policy ACCEPT)
num target prot opt source destination
...
14 ACCEPT tcp -- old.myISP.com anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num target prot opt source destination
...
3 DROP all -- anywhere anywhere recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source
Editing the rules in /etc/iptables.rules
Change
-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT
to
-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT
where 111.222.33.44 is the new face IP.
And read in the adapted rules:
# iptables-restore < /etc/iptables.rules
answered Mar 17 '14 at 16:06
PhilippPhilipp
15618
add a comment |
The iptables rules on the server had a an "anti ssh bruteforce" rule chain which uses the "recent" module to drop connections after 4 attempts were made within 1 minute.
This rule had an exception in the INPUT chain, to allow all ssh from our face IP. As we moved, the face IP changed, and the rule had to be adapted. For reference, this is how I did this
List all iptables rules
# iptables -L --line-numbers
Notice the accept rule in the INPUT chain, which was set to accept all ssh connections from our (previous) face IP address and the anti bruteforce rule which drops ssh connections after several attempts in the SSH_CHECK chain:
Chain INPUT (policy ACCEPT)
num target prot opt source destination
...
14 ACCEPT tcp -- old.myISP.com anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num target prot opt source destination
...
3 DROP all -- anywhere anywhere recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source
Editing the rules in /etc/iptables.rules
Change
-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT
to
-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT
where 111.222.33.44 is the new face IP.
And read in the adapted rules:
# iptables-restore < /etc/iptables.rules
answered Mar 17 '14 at 16:06
PhilippPhilipp
15618
add a comment |
The iptables rules on the server had a an "anti ssh bruteforce" rule chain which uses the "recent" module to drop connections after 4 attempts were made within 1 minute.
This rule had an exception in the INPUT chain, to allow all ssh from our face IP. As we moved, the face IP changed, and the rule had to be adapted. For reference, this is how I did this
List all iptables rules
# iptables -L --line-numbers
Notice the accept rule in the INPUT chain, which was set to accept all ssh connections from our (previous) face IP address and the anti bruteforce rule which drops ssh connections after several attempts in the SSH_CHECK chain:
Chain INPUT (policy ACCEPT)
num target prot opt source destination
...
14 ACCEPT tcp -- old.myISP.com anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num target prot opt source destination
...
3 DROP all -- anywhere anywhere recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source
Editing the rules in /etc/iptables.rules
Change
-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT
to
-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT
where 111.222.33.44 is the new face IP.
And read in the adapted rules:
# iptables-restore < /etc/iptables.rules
answered Mar 17 '14 at 16:06
PhilippPhilipp
15618
The iptables rules on the server had a an "anti ssh bruteforce" rule chain which uses the "recent" module to drop connections after 4 attempts were made within 1 minute.
This rule had an exception in the INPUT chain, to allow all ssh from our face IP. As we moved, the face IP changed, and the rule had to be adapted. For reference, this is how I did this
List all iptables rules
# iptables -L --line-numbers
Notice the accept rule in the INPUT chain, which was set to accept all ssh connections from our (previous) face IP address and the anti bruteforce rule which drops ssh connections after several attempts in the SSH_CHECK chain:
Chain INPUT (policy ACCEPT)
num target prot opt source destination
...
14 ACCEPT tcp -- old.myISP.com anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num target prot opt source destination
...
3 DROP all -- anywhere anywhere recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source
Editing the rules in /etc/iptables.rules
Change
-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT
to
-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT
where 111.222.33.44 is the new face IP.
And read in the adapted rules:
# iptables-restore < /etc/iptables.rules
answered Mar 17 '14 at 16:06
PhilippPhilipp
15618
answered Mar 17 '14 at 16:06
PhilippPhilipp
15618
answered Mar 17 '14 at 16:06
PhilippPhilipp
15618
answered Mar 17 '14 at 16:06
PhilippPhilipp
15618
15618
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f725561%2fconnection-requests-hang-with-syn-sent-after-a-few-tries%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
