Can't forward internet via to wlan via eth | iptables restore command not working
I have a NanoPi M1 Plus device with Ubuntu OS in it which I am using it as a router. The device is getting the internet via ethernet cable (eth0 interface) and the WiFi AP is provided via interface wlan0.
I have written the iptables rules, but it doesn't seem to work. And IP_FORWARDING has been enabled.
Also, on executing iptables-restore > /etc/iptables.ipv4.nat command it just freezes and no output is printed on the terminal.
iptables.ipv4.nat
*filter
:INPUT ACCEPT [186:14306]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [131:13477]
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [142:11472]
:INPUT ACCEPT [27:2092]
:OUTPUT ACCEPT [28:2049]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
What is the issue here?
linux networking wireless-networking iptables nat
asked Dec 14 at 4:25
ron123456
187
add a comment |
I have a NanoPi M1 Plus device with Ubuntu OS in it which I am using it as a router. The device is getting the internet via ethernet cable (eth0 interface) and the WiFi AP is provided via interface wlan0.
I have written the iptables rules, but it doesn't seem to work. And IP_FORWARDING has been enabled.
Also, on executing iptables-restore > /etc/iptables.ipv4.nat command it just freezes and no output is printed on the terminal.
iptables.ipv4.nat
*filter
:INPUT ACCEPT [186:14306]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [131:13477]
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [142:11472]
:INPUT ACCEPT [27:2092]
:OUTPUT ACCEPT [28:2049]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
What is the issue here?
linux networking wireless-networking iptables nat
asked Dec 14 at 4:25
ron123456
187
"I have written the iptables rules" – do you mean you've only added them to the ruleset in /etc, or do you mean you've also loaded them via iptables into the kernel? The former won't take any effect until loaded.
– grawity
Dec 14 at 5:50
I have loaded them in to the kernel
– ron123456
Dec 14 at 6:56
add a comment |
I have a NanoPi M1 Plus device with Ubuntu OS in it which I am using it as a router. The device is getting the internet via ethernet cable (eth0 interface) and the WiFi AP is provided via interface wlan0.
I have written the iptables rules, but it doesn't seem to work. And IP_FORWARDING has been enabled.
Also, on executing iptables-restore > /etc/iptables.ipv4.nat command it just freezes and no output is printed on the terminal.
iptables.ipv4.nat
*filter
:INPUT ACCEPT [186:14306]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [131:13477]
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [142:11472]
:INPUT ACCEPT [27:2092]
:OUTPUT ACCEPT [28:2049]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
What is the issue here?
linux networking wireless-networking iptables nat
asked Dec 14 at 4:25
ron123456
187
I have a NanoPi M1 Plus device with Ubuntu OS in it which I am using it as a router. The device is getting the internet via ethernet cable (eth0 interface) and the WiFi AP is provided via interface wlan0.
I have written the iptables rules, but it doesn't seem to work. And IP_FORWARDING has been enabled.
Also, on executing iptables-restore > /etc/iptables.ipv4.nat command it just freezes and no output is printed on the terminal.
iptables.ipv4.nat
*filter
:INPUT ACCEPT [186:14306]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [131:13477]
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [142:11472]
:INPUT ACCEPT [27:2092]
:OUTPUT ACCEPT [28:2049]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
What is the issue here?
linux networking wireless-networking iptables nat
linux networking wireless-networking iptables nat
asked Dec 14 at 4:25
ron123456
187
asked Dec 14 at 4:25
ron123456
187
asked Dec 14 at 4:25
ron123456
187
asked Dec 14 at 4:25
ron123456
187
asked Dec 14 at 4:25
ron123456
187
187
"I have written the iptables rules" – do you mean you've only added them to the ruleset in /etc, or do you mean you've also loaded them via iptables into the kernel? The former won't take any effect until loaded.
– grawity
Dec 14 at 5:50
I have loaded them in to the kernel
– ron123456
Dec 14 at 6:56
add a comment |
"I have written the iptables rules" – do you mean you've only added them to the ruleset in /etc, or do you mean you've also loaded them via iptables into the kernel? The former won't take any effect until loaded.
– grawity
Dec 14 at 5:50
I have loaded them in to the kernel
– ron123456
Dec 14 at 6:56
"I have written the iptables rules" – do you mean you've only added them to the ruleset in /etc, or do you mean you've also loaded them via iptables into the kernel? The former won't take any effect until loaded.
– grawity
Dec 14 at 5:50
"I have written the iptables rules" – do you mean you've only added them to the ruleset in /etc, or do you mean you've also loaded them via iptables into the kernel? The former won't take any effect until loaded.
– grawity
Dec 14 at 5:50
I have loaded them in to the kernel
– ron123456
Dec 14 at 6:56
I have loaded them in to the kernel
– ron123456
Dec 14 at 6:56
add a comment |
1 Answer
1
active
oldest
votes
Also, on executing
iptables-restore > /etc/iptables.ipv4.natcommand it just freezes and no output is printed on the terminal.
It is waiting for input. The purpose of iptables-restore is to read the ruleset from a file, but you used the wrong redirection operator and told the shell to write to that file. The correct operator with this command is <.
Note that using > has immediately emptied the file's previous contents, so make sure to re-fill it with rules before trying again.
Other than that, the ruleset does not have any obvious problems. You might be having issues elsewhere, especially with the uRPF filtering feature which would refuse to accept packets from the "wrong" interface. Make sure to disable it via sysctl, by setting net.ipv4.conf.all.rp_filter to 0 for 'off' (or 2 for 'loose').
answered Dec 14 at 5:50
grawity
231k35488545
Yes, I was using the wrong operator. Though it didn't work for eth0 to wlan0 forwarding even after disablingnet.ipv4.conf.all.rp_filter. But if I use an external wifi interface wlan1 as the station and make changes in iptables i.e.usingwlan1instead ofeth0.. iptables forwarding works perfectly
– ron123456
Dec 18 at 8:50
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%2f1383473%2fcant-forward-internet-via-to-wlan-via-eth-iptables-restore-command-not-workin%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
Also, on executing
iptables-restore > /etc/iptables.ipv4.natcommand it just freezes and no output is printed on the terminal.
It is waiting for input. The purpose of iptables-restore is to read the ruleset from a file, but you used the wrong redirection operator and told the shell to write to that file. The correct operator with this command is <.
Note that using > has immediately emptied the file's previous contents, so make sure to re-fill it with rules before trying again.
Other than that, the ruleset does not have any obvious problems. You might be having issues elsewhere, especially with the uRPF filtering feature which would refuse to accept packets from the "wrong" interface. Make sure to disable it via sysctl, by setting net.ipv4.conf.all.rp_filter to 0 for 'off' (or 2 for 'loose').
answered Dec 14 at 5:50
grawity
231k35488545
Yes, I was using the wrong operator. Though it didn't work for eth0 to wlan0 forwarding even after disablingnet.ipv4.conf.all.rp_filter. But if I use an external wifi interface wlan1 as the station and make changes in iptables i.e.usingwlan1instead ofeth0.. iptables forwarding works perfectly
– ron123456
Dec 18 at 8:50
add a comment |
Also, on executing
iptables-restore > /etc/iptables.ipv4.natcommand it just freezes and no output is printed on the terminal.
It is waiting for input. The purpose of iptables-restore is to read the ruleset from a file, but you used the wrong redirection operator and told the shell to write to that file. The correct operator with this command is <.
Note that using > has immediately emptied the file's previous contents, so make sure to re-fill it with rules before trying again.
Other than that, the ruleset does not have any obvious problems. You might be having issues elsewhere, especially with the uRPF filtering feature which would refuse to accept packets from the "wrong" interface. Make sure to disable it via sysctl, by setting net.ipv4.conf.all.rp_filter to 0 for 'off' (or 2 for 'loose').
answered Dec 14 at 5:50
grawity
231k35488545
Yes, I was using the wrong operator. Though it didn't work for eth0 to wlan0 forwarding even after disablingnet.ipv4.conf.all.rp_filter. But if I use an external wifi interface wlan1 as the station and make changes in iptables i.e.usingwlan1instead ofeth0.. iptables forwarding works perfectly
– ron123456
Dec 18 at 8:50
add a comment |
Also, on executing
iptables-restore > /etc/iptables.ipv4.natcommand it just freezes and no output is printed on the terminal.
It is waiting for input. The purpose of iptables-restore is to read the ruleset from a file, but you used the wrong redirection operator and told the shell to write to that file. The correct operator with this command is <.
Note that using > has immediately emptied the file's previous contents, so make sure to re-fill it with rules before trying again.
Other than that, the ruleset does not have any obvious problems. You might be having issues elsewhere, especially with the uRPF filtering feature which would refuse to accept packets from the "wrong" interface. Make sure to disable it via sysctl, by setting net.ipv4.conf.all.rp_filter to 0 for 'off' (or 2 for 'loose').
answered Dec 14 at 5:50
grawity
231k35488545
Also, on executing
iptables-restore > /etc/iptables.ipv4.natcommand it just freezes and no output is printed on the terminal.
It is waiting for input. The purpose of iptables-restore is to read the ruleset from a file, but you used the wrong redirection operator and told the shell to write to that file. The correct operator with this command is <.
Note that using > has immediately emptied the file's previous contents, so make sure to re-fill it with rules before trying again.
Other than that, the ruleset does not have any obvious problems. You might be having issues elsewhere, especially with the uRPF filtering feature which would refuse to accept packets from the "wrong" interface. Make sure to disable it via sysctl, by setting net.ipv4.conf.all.rp_filter to 0 for 'off' (or 2 for 'loose').
answered Dec 14 at 5:50
grawity
231k35488545
answered Dec 14 at 5:50
grawity
231k35488545
answered Dec 14 at 5:50
grawity
231k35488545
answered Dec 14 at 5:50
grawity
231k35488545
231k35488545
Yes, I was using the wrong operator. Though it didn't work for eth0 to wlan0 forwarding even after disablingnet.ipv4.conf.all.rp_filter. But if I use an external wifi interface wlan1 as the station and make changes in iptables i.e.usingwlan1instead ofeth0.. iptables forwarding works perfectly
– ron123456
Dec 18 at 8:50
add a comment |
Yes, I was using the wrong operator. Though it didn't work for eth0 to wlan0 forwarding even after disablingnet.ipv4.conf.all.rp_filter. But if I use an external wifi interface wlan1 as the station and make changes in iptables i.e.usingwlan1instead ofeth0.. iptables forwarding works perfectly
– ron123456
Dec 18 at 8:50
Yes, I was using the wrong operator. Though it didn't work for eth0 to wlan0 forwarding even after disabling
net.ipv4.conf.all.rp_filter. But if I use an external wifi interface wlan1 as the station and make changes in iptables i.e.using wlan1 instead of eth0 .. iptables forwarding works perfectly– ron123456
Dec 18 at 8:50
Yes, I was using the wrong operator. Though it didn't work for eth0 to wlan0 forwarding even after disabling
net.ipv4.conf.all.rp_filter. But if I use an external wifi interface wlan1 as the station and make changes in iptables i.e.using wlan1 instead of eth0 .. iptables forwarding works perfectly– ron123456
Dec 18 at 8:50
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.
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%2fsuperuser.com%2fquestions%2f1383473%2fcant-forward-internet-via-to-wlan-via-eth-iptables-restore-command-not-workin%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
"I have written the iptables rules" – do you mean you've only added them to the ruleset in /etc, or do you mean you've also loaded them via iptables into the kernel? The former won't take any effect until loaded.
– grawity
Dec 14 at 5:50
I have loaded them in to the kernel
– ron123456
Dec 14 at 6:56