IPTables Port Redirection Should Have Broken Apache But Didn't
I have a Load Balance set up in Apache httpd
:
<VirtualHost *:80>
DocumentRoot /var/www/html
ServerName xxx.xxx.xxx.com
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://xxx.xxx.xxx.xxx:8080/
ProxyPassReverse / http://xxx.xxx.xxx.xxx:8080/
</VirtualHost>
:8080
is an Apache tomcat
application server running on the same host. We have log retention requirements where I work, so I figured making everything apache httpd
would make things ideal for analytics.
I was attempting to get all public requests to go through port 80 without breaking any links or bookmarks end users might have. I was going to do that by doing some port translation so that everything looked like it was coming in via port 80 to applications. Without thinking about my load balance above I added the following rules to the nat
table:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8081 -j REDIRECT --to-ports 80
Problem is, that I can get to the application either through httpd
or directly by going to :8080
. The packet count is also going up on each rule so apparently they're being matched against.
My question is this: Why didn't this just create an infinite loop?
It would seem the :8080
requests would get forwarded to httpd
which would itself attempt to retrieve them by going over :8080
and thus the circle would continue onwards until I was reformatting my new resume.
linux iptables tomcat apache-httpd
add a comment |
I have a Load Balance set up in Apache httpd
:
<VirtualHost *:80>
DocumentRoot /var/www/html
ServerName xxx.xxx.xxx.com
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://xxx.xxx.xxx.xxx:8080/
ProxyPassReverse / http://xxx.xxx.xxx.xxx:8080/
</VirtualHost>
:8080
is an Apache tomcat
application server running on the same host. We have log retention requirements where I work, so I figured making everything apache httpd
would make things ideal for analytics.
I was attempting to get all public requests to go through port 80 without breaking any links or bookmarks end users might have. I was going to do that by doing some port translation so that everything looked like it was coming in via port 80 to applications. Without thinking about my load balance above I added the following rules to the nat
table:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8081 -j REDIRECT --to-ports 80
Problem is, that I can get to the application either through httpd
or directly by going to :8080
. The packet count is also going up on each rule so apparently they're being matched against.
My question is this: Why didn't this just create an infinite loop?
It would seem the :8080
requests would get forwarded to httpd
which would itself attempt to retrieve them by going over :8080
and thus the circle would continue onwards until I was reformatting my new resume.
linux iptables tomcat apache-httpd
add a comment |
I have a Load Balance set up in Apache httpd
:
<VirtualHost *:80>
DocumentRoot /var/www/html
ServerName xxx.xxx.xxx.com
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://xxx.xxx.xxx.xxx:8080/
ProxyPassReverse / http://xxx.xxx.xxx.xxx:8080/
</VirtualHost>
:8080
is an Apache tomcat
application server running on the same host. We have log retention requirements where I work, so I figured making everything apache httpd
would make things ideal for analytics.
I was attempting to get all public requests to go through port 80 without breaking any links or bookmarks end users might have. I was going to do that by doing some port translation so that everything looked like it was coming in via port 80 to applications. Without thinking about my load balance above I added the following rules to the nat
table:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8081 -j REDIRECT --to-ports 80
Problem is, that I can get to the application either through httpd
or directly by going to :8080
. The packet count is also going up on each rule so apparently they're being matched against.
My question is this: Why didn't this just create an infinite loop?
It would seem the :8080
requests would get forwarded to httpd
which would itself attempt to retrieve them by going over :8080
and thus the circle would continue onwards until I was reformatting my new resume.
linux iptables tomcat apache-httpd
I have a Load Balance set up in Apache httpd
:
<VirtualHost *:80>
DocumentRoot /var/www/html
ServerName xxx.xxx.xxx.com
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://xxx.xxx.xxx.xxx:8080/
ProxyPassReverse / http://xxx.xxx.xxx.xxx:8080/
</VirtualHost>
:8080
is an Apache tomcat
application server running on the same host. We have log retention requirements where I work, so I figured making everything apache httpd
would make things ideal for analytics.
I was attempting to get all public requests to go through port 80 without breaking any links or bookmarks end users might have. I was going to do that by doing some port translation so that everything looked like it was coming in via port 80 to applications. Without thinking about my load balance above I added the following rules to the nat
table:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8081 -j REDIRECT --to-ports 80
Problem is, that I can get to the application either through httpd
or directly by going to :8080
. The packet count is also going up on each rule so apparently they're being matched against.
My question is this: Why didn't this just create an infinite loop?
It would seem the :8080
requests would get forwarded to httpd
which would itself attempt to retrieve them by going over :8080
and thus the circle would continue onwards until I was reformatting my new resume.
linux iptables tomcat apache-httpd
linux iptables tomcat apache-httpd
edited 2 hours ago
Rui F Ribeiro
39.6k1479132
39.6k1479132
asked May 16 '14 at 17:41
BratchleyBratchley
12k74388
12k74388
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The answer lies in -i eth0
.
Even though you have httpd set to connect to 17.98.65.28
, which I assume is an IP on eth0
, the traffic won't actually flow over eth0
, it'll use lo
instead.
The reason for this is that when routing to any IP the box has on itself, that traffic flows over lo
. You can verify this with the following:
ip route get 17.98.65.28
You will get a line back that contains dev lo
, this tells you which interface will be used to send traffic to that address.
For example, on my laptop, I have wlan0
with 10.252.28.62
:
$ ip route get 10.252.28.62
local 10.252.28.62 dev lo src 10.252.28.62
cache <local>
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f130665%2fiptables-port-redirection-should-have-broken-apache-but-didnt%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 answer lies in -i eth0
.
Even though you have httpd set to connect to 17.98.65.28
, which I assume is an IP on eth0
, the traffic won't actually flow over eth0
, it'll use lo
instead.
The reason for this is that when routing to any IP the box has on itself, that traffic flows over lo
. You can verify this with the following:
ip route get 17.98.65.28
You will get a line back that contains dev lo
, this tells you which interface will be used to send traffic to that address.
For example, on my laptop, I have wlan0
with 10.252.28.62
:
$ ip route get 10.252.28.62
local 10.252.28.62 dev lo src 10.252.28.62
cache <local>
add a comment |
The answer lies in -i eth0
.
Even though you have httpd set to connect to 17.98.65.28
, which I assume is an IP on eth0
, the traffic won't actually flow over eth0
, it'll use lo
instead.
The reason for this is that when routing to any IP the box has on itself, that traffic flows over lo
. You can verify this with the following:
ip route get 17.98.65.28
You will get a line back that contains dev lo
, this tells you which interface will be used to send traffic to that address.
For example, on my laptop, I have wlan0
with 10.252.28.62
:
$ ip route get 10.252.28.62
local 10.252.28.62 dev lo src 10.252.28.62
cache <local>
add a comment |
The answer lies in -i eth0
.
Even though you have httpd set to connect to 17.98.65.28
, which I assume is an IP on eth0
, the traffic won't actually flow over eth0
, it'll use lo
instead.
The reason for this is that when routing to any IP the box has on itself, that traffic flows over lo
. You can verify this with the following:
ip route get 17.98.65.28
You will get a line back that contains dev lo
, this tells you which interface will be used to send traffic to that address.
For example, on my laptop, I have wlan0
with 10.252.28.62
:
$ ip route get 10.252.28.62
local 10.252.28.62 dev lo src 10.252.28.62
cache <local>
The answer lies in -i eth0
.
Even though you have httpd set to connect to 17.98.65.28
, which I assume is an IP on eth0
, the traffic won't actually flow over eth0
, it'll use lo
instead.
The reason for this is that when routing to any IP the box has on itself, that traffic flows over lo
. You can verify this with the following:
ip route get 17.98.65.28
You will get a line back that contains dev lo
, this tells you which interface will be used to send traffic to that address.
For example, on my laptop, I have wlan0
with 10.252.28.62
:
$ ip route get 10.252.28.62
local 10.252.28.62 dev lo src 10.252.28.62
cache <local>
answered May 16 '14 at 17:52
PatrickPatrick
50.3k11127179
50.3k11127179
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f130665%2fiptables-port-redirection-should-have-broken-apache-but-didnt%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