Source NAT rule for LXC containers
I've just noticed that MASQUERADE
iptables
rule added by lxc
has ! -d
part:
iptables -t nat -A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
My guess is that -s 10.0.3.0/24 -d 10.0.3.0/24
can only be observed when sending data from one container to the other one (ping
, ssh
, you name it). And omitting the ! -d
part can only affect performance. To unknown extent. Am I right?
iptables lxc nat
add a comment |
I've just noticed that MASQUERADE
iptables
rule added by lxc
has ! -d
part:
iptables -t nat -A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
My guess is that -s 10.0.3.0/24 -d 10.0.3.0/24
can only be observed when sending data from one container to the other one (ping
, ssh
, you name it). And omitting the ! -d
part can only affect performance. To unknown extent. Am I right?
iptables lxc nat
add a comment |
I've just noticed that MASQUERADE
iptables
rule added by lxc
has ! -d
part:
iptables -t nat -A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
My guess is that -s 10.0.3.0/24 -d 10.0.3.0/24
can only be observed when sending data from one container to the other one (ping
, ssh
, you name it). And omitting the ! -d
part can only affect performance. To unknown extent. Am I right?
iptables lxc nat
I've just noticed that MASQUERADE
iptables
rule added by lxc
has ! -d
part:
iptables -t nat -A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
My guess is that -s 10.0.3.0/24 -d 10.0.3.0/24
can only be observed when sending data from one container to the other one (ping
, ssh
, you name it). And omitting the ! -d
part can only affect performance. To unknown extent. Am I right?
iptables lxc nat
iptables lxc nat
asked Dec 27 '18 at 16:55
x-yurix-yuri
1,17811642
1,17811642
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
This rule allows two different containers on the same subnet to talk to each other without being NAT'd
So a container with 10.0.3.100 talking to 10.0.3.101 will appear as 10.0.3.100 to the other container and not as the host address.
This can be beneficial for various purposes (e.g. logging of activity, access controls) because the target container can identify the source container. It also allows these containers to not need default routes (it's all local subnet) so can be beneficial from a security perspective.
And, of course, it removes unnecessary NAT overhead!
I just tried to run two LXC containers (10.0.0.100
,10.0.0.200
) on local machine withiptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
,tcpdump icmp
on one,ping -c 1 10.0.0.100
on the other. Andtcpdump
says the IP is10.0.0.200
.
– x-yuri
Dec 28 '18 at 7:27
I was told that by default iptables doesn't process inter-container traffic, but that can be enabled system-wide.
– x-yuri
Dec 28 '18 at 13:06
Yeah, it's part of the "defensive configuration"; build for the worst case (what if...) so that changes made elsewhere don't break the local stuff.
– Stephen Harris
Dec 28 '18 at 13:28
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%2f491166%2fsource-nat-rule-for-lxc-containers%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
This rule allows two different containers on the same subnet to talk to each other without being NAT'd
So a container with 10.0.3.100 talking to 10.0.3.101 will appear as 10.0.3.100 to the other container and not as the host address.
This can be beneficial for various purposes (e.g. logging of activity, access controls) because the target container can identify the source container. It also allows these containers to not need default routes (it's all local subnet) so can be beneficial from a security perspective.
And, of course, it removes unnecessary NAT overhead!
I just tried to run two LXC containers (10.0.0.100
,10.0.0.200
) on local machine withiptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
,tcpdump icmp
on one,ping -c 1 10.0.0.100
on the other. Andtcpdump
says the IP is10.0.0.200
.
– x-yuri
Dec 28 '18 at 7:27
I was told that by default iptables doesn't process inter-container traffic, but that can be enabled system-wide.
– x-yuri
Dec 28 '18 at 13:06
Yeah, it's part of the "defensive configuration"; build for the worst case (what if...) so that changes made elsewhere don't break the local stuff.
– Stephen Harris
Dec 28 '18 at 13:28
add a comment |
This rule allows two different containers on the same subnet to talk to each other without being NAT'd
So a container with 10.0.3.100 talking to 10.0.3.101 will appear as 10.0.3.100 to the other container and not as the host address.
This can be beneficial for various purposes (e.g. logging of activity, access controls) because the target container can identify the source container. It also allows these containers to not need default routes (it's all local subnet) so can be beneficial from a security perspective.
And, of course, it removes unnecessary NAT overhead!
I just tried to run two LXC containers (10.0.0.100
,10.0.0.200
) on local machine withiptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
,tcpdump icmp
on one,ping -c 1 10.0.0.100
on the other. Andtcpdump
says the IP is10.0.0.200
.
– x-yuri
Dec 28 '18 at 7:27
I was told that by default iptables doesn't process inter-container traffic, but that can be enabled system-wide.
– x-yuri
Dec 28 '18 at 13:06
Yeah, it's part of the "defensive configuration"; build for the worst case (what if...) so that changes made elsewhere don't break the local stuff.
– Stephen Harris
Dec 28 '18 at 13:28
add a comment |
This rule allows two different containers on the same subnet to talk to each other without being NAT'd
So a container with 10.0.3.100 talking to 10.0.3.101 will appear as 10.0.3.100 to the other container and not as the host address.
This can be beneficial for various purposes (e.g. logging of activity, access controls) because the target container can identify the source container. It also allows these containers to not need default routes (it's all local subnet) so can be beneficial from a security perspective.
And, of course, it removes unnecessary NAT overhead!
This rule allows two different containers on the same subnet to talk to each other without being NAT'd
So a container with 10.0.3.100 talking to 10.0.3.101 will appear as 10.0.3.100 to the other container and not as the host address.
This can be beneficial for various purposes (e.g. logging of activity, access controls) because the target container can identify the source container. It also allows these containers to not need default routes (it's all local subnet) so can be beneficial from a security perspective.
And, of course, it removes unnecessary NAT overhead!
answered Dec 28 '18 at 2:01
Stephen HarrisStephen Harris
25.3k24477
25.3k24477
I just tried to run two LXC containers (10.0.0.100
,10.0.0.200
) on local machine withiptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
,tcpdump icmp
on one,ping -c 1 10.0.0.100
on the other. Andtcpdump
says the IP is10.0.0.200
.
– x-yuri
Dec 28 '18 at 7:27
I was told that by default iptables doesn't process inter-container traffic, but that can be enabled system-wide.
– x-yuri
Dec 28 '18 at 13:06
Yeah, it's part of the "defensive configuration"; build for the worst case (what if...) so that changes made elsewhere don't break the local stuff.
– Stephen Harris
Dec 28 '18 at 13:28
add a comment |
I just tried to run two LXC containers (10.0.0.100
,10.0.0.200
) on local machine withiptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
,tcpdump icmp
on one,ping -c 1 10.0.0.100
on the other. Andtcpdump
says the IP is10.0.0.200
.
– x-yuri
Dec 28 '18 at 7:27
I was told that by default iptables doesn't process inter-container traffic, but that can be enabled system-wide.
– x-yuri
Dec 28 '18 at 13:06
Yeah, it's part of the "defensive configuration"; build for the worst case (what if...) so that changes made elsewhere don't break the local stuff.
– Stephen Harris
Dec 28 '18 at 13:28
I just tried to run two LXC containers (
10.0.0.100
, 10.0.0.200
) on local machine with iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
, tcpdump icmp
on one, ping -c 1 10.0.0.100
on the other. And tcpdump
says the IP is 10.0.0.200
.– x-yuri
Dec 28 '18 at 7:27
I just tried to run two LXC containers (
10.0.0.100
, 10.0.0.200
) on local machine with iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
, tcpdump icmp
on one, ping -c 1 10.0.0.100
on the other. And tcpdump
says the IP is 10.0.0.200
.– x-yuri
Dec 28 '18 at 7:27
I was told that by default iptables doesn't process inter-container traffic, but that can be enabled system-wide.
– x-yuri
Dec 28 '18 at 13:06
I was told that by default iptables doesn't process inter-container traffic, but that can be enabled system-wide.
– x-yuri
Dec 28 '18 at 13:06
Yeah, it's part of the "defensive configuration"; build for the worst case (what if...) so that changes made elsewhere don't break the local stuff.
– Stephen Harris
Dec 28 '18 at 13:28
Yeah, it's part of the "defensive configuration"; build for the worst case (what if...) so that changes made elsewhere don't break the local stuff.
– Stephen Harris
Dec 28 '18 at 13:28
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f491166%2fsource-nat-rule-for-lxc-containers%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