Can't forward internet via to wlan via eth | iptables restore command not working












0














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?










share|improve this question






















  • "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 '18 at 5:50












  • I have loaded them in to the kernel
    – ron123456
    Dec 14 '18 at 6:56
















0














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?










share|improve this question






















  • "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 '18 at 5:50












  • I have loaded them in to the kernel
    – ron123456
    Dec 14 '18 at 6:56














0












0








0







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?










share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Dec 14 '18 at 4:25









ron123456ron123456

207




207












  • "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 '18 at 5:50












  • I have loaded them in to the kernel
    – ron123456
    Dec 14 '18 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 '18 at 5:50












  • I have loaded them in to the kernel
    – ron123456
    Dec 14 '18 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 '18 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 '18 at 5:50














I have loaded them in to the kernel
– ron123456
Dec 14 '18 at 6:56




I have loaded them in to the kernel
– ron123456
Dec 14 '18 at 6:56










1 Answer
1






active

oldest

votes


















2















Also, on executing iptables-restore > /etc/iptables.ipv4.nat command 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').






share|improve this answer





















  • 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 '18 at 8:50













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
});


}
});














draft saved

draft discarded


















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









2















Also, on executing iptables-restore > /etc/iptables.ipv4.nat command 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').






share|improve this answer





















  • 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 '18 at 8:50


















2















Also, on executing iptables-restore > /etc/iptables.ipv4.nat command 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').






share|improve this answer





















  • 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 '18 at 8:50
















2












2








2







Also, on executing iptables-restore > /etc/iptables.ipv4.nat command 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').






share|improve this answer













Also, on executing iptables-restore > /etc/iptables.ipv4.nat command 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').







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 14 '18 at 5:50









grawitygrawity

233k36493547




233k36493547












  • 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 '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 '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 '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 '18 at 8:50




















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Plaza Victoria

Puebla de Zaragoza

Musa