Using bridge utils to connect two computers via Linux
I have been using bridge utils previously to connect my network connected computers to a single interface on my Linux computer. The problem I'm having is when I installed a new Linux (with Slackware) the two connected computers cannot even ping each other. Basically the computers are connected as:
client - server - client
|
[Internet]
So I am trying to get the two clients to connect to each other. Both can access the Internet, firewalls are shut off at both clients when testing.
Internet is on eth0, and I have one bridge set up as
bridge name interfaces
br0 eth1, eth2
ip addr br0 and ip route show shows respectively
inet 10.0.0.1/24 brd 10.0.0.255
10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1
So it seems to me like a call from my client should be routed directly to my br0 interface, which should get it right.
How do I configure my Slackware distro to route two network cable attached computers to be able to see eachother, preferably using bridge utils?
linux networking routing bridge
edited 3 hours ago
Rui F Ribeiro
41.5k1483140
asked Oct 4 '10 at 10:27
PatrickPatrick
14827
add a comment |
I have been using bridge utils previously to connect my network connected computers to a single interface on my Linux computer. The problem I'm having is when I installed a new Linux (with Slackware) the two connected computers cannot even ping each other. Basically the computers are connected as:
client - server - client
|
[Internet]
So I am trying to get the two clients to connect to each other. Both can access the Internet, firewalls are shut off at both clients when testing.
Internet is on eth0, and I have one bridge set up as
bridge name interfaces
br0 eth1, eth2
ip addr br0 and ip route show shows respectively
inet 10.0.0.1/24 brd 10.0.0.255
10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1
So it seems to me like a call from my client should be routed directly to my br0 interface, which should get it right.
How do I configure my Slackware distro to route two network cable attached computers to be able to see eachother, preferably using bridge utils?
linux networking routing bridge
edited 3 hours ago
Rui F Ribeiro
41.5k1483140
asked Oct 4 '10 at 10:27
PatrickPatrick
14827
add a comment |
I have been using bridge utils previously to connect my network connected computers to a single interface on my Linux computer. The problem I'm having is when I installed a new Linux (with Slackware) the two connected computers cannot even ping each other. Basically the computers are connected as:
client - server - client
|
[Internet]
So I am trying to get the two clients to connect to each other. Both can access the Internet, firewalls are shut off at both clients when testing.
Internet is on eth0, and I have one bridge set up as
bridge name interfaces
br0 eth1, eth2
ip addr br0 and ip route show shows respectively
inet 10.0.0.1/24 brd 10.0.0.255
10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1
So it seems to me like a call from my client should be routed directly to my br0 interface, which should get it right.
How do I configure my Slackware distro to route two network cable attached computers to be able to see eachother, preferably using bridge utils?
linux networking routing bridge
edited 3 hours ago
Rui F Ribeiro
41.5k1483140
asked Oct 4 '10 at 10:27
PatrickPatrick
14827
I have been using bridge utils previously to connect my network connected computers to a single interface on my Linux computer. The problem I'm having is when I installed a new Linux (with Slackware) the two connected computers cannot even ping each other. Basically the computers are connected as:
client - server - client
|
[Internet]
So I am trying to get the two clients to connect to each other. Both can access the Internet, firewalls are shut off at both clients when testing.
Internet is on eth0, and I have one bridge set up as
bridge name interfaces
br0 eth1, eth2
ip addr br0 and ip route show shows respectively
inet 10.0.0.1/24 brd 10.0.0.255
10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1
So it seems to me like a call from my client should be routed directly to my br0 interface, which should get it right.
How do I configure my Slackware distro to route two network cable attached computers to be able to see eachother, preferably using bridge utils?
linux networking routing bridge
linux networking routing bridge
edited 3 hours ago
Rui F Ribeiro
41.5k1483140
asked Oct 4 '10 at 10:27
PatrickPatrick
14827
edited 3 hours ago
Rui F Ribeiro
41.5k1483140
asked Oct 4 '10 at 10:27
PatrickPatrick
14827
edited 3 hours ago
Rui F Ribeiro
41.5k1483140
edited 3 hours ago
Rui F Ribeiro
41.5k1483140
edited 3 hours ago
Rui F Ribeiro
41.5k1483140
41.5k1483140
asked Oct 4 '10 at 10:27
PatrickPatrick
14827
asked Oct 4 '10 at 10:27
PatrickPatrick
14827
asked Oct 4 '10 at 10:27
PatrickPatrick
14827
14827
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Is the firewall on the server disabled? It maybe that there are some firewall rules that are blocking the packets. Look at the output of iptables (must be run as root) and if you see anything other than ACCEPT rules/policies then they may be blocking things.
iptables -L
and
iptables -t nat -L
answered Oct 4 '10 at 14:13
RichmRichm
3,1641612
I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?
– Patrick
Oct 4 '10 at 14:35
1
"man iptables" is your friend :-)
– Richm
Oct 4 '10 at 14:53
1
But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.
– Richm
Oct 4 '10 at 14:56
@Richm: Well whaddayaknow.iptables -P FORWARD ACCEPTmade the magic happen.. Now I just need to figure out how I can set this to LAN only..
– Patrick
Oct 4 '10 at 15:47
1
The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.
– Richm
Oct 4 '10 at 16:52
|
show 1 more comment
If the two devices cannot ping each other it sounds like the bridge is not correctly setup. There is no ip protocol routing involved in the bridge. What is the output of brctl show ? That should show something like
$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.003018a46079 no eth1
eth2
If both interfaces are not listed there then that needs correcting.
You may also like to try the brctl showmacs br0 command and if STP (spanning tree protocol) was enabled above the brctl showstp br0 command. The former should show the mac addresses of the two devices and the for the latter you should look to make sure that each port is in state forwarding
Given that you say that each can access the internet I assume that all of the interfaces have been brought up. If not the following should do that.
ip link set br0 up
ip link set eth0 up
ip link set eth1 up
ip link set eth2 up
answered Oct 4 '10 at 11:34
RichmRichm
3,1641612
brctl showdisplays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed byip a show.
– Patrick
Oct 4 '10 at 12:46
add a comment |
Check if ip fowarding is enabled on the server with the command
sysctl net.ipv4.ip_forward
if this gives 0, do
sysctl -w net.ipv4.ip_forward=1
as root on the server. If this helps, make the change permanent by editing /etc/sysctl.conf
answered Oct 4 '10 at 10:52
fschmittfschmitt
7,6713043
it printsnet.ipv4.ip_forward = 1, so no dice unfortunately.
– Patrick
Oct 4 '10 at 10:58
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%2f2696%2fusing-bridge-utils-to-connect-two-computers-via-linux%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Is the firewall on the server disabled? It maybe that there are some firewall rules that are blocking the packets. Look at the output of iptables (must be run as root) and if you see anything other than ACCEPT rules/policies then they may be blocking things.
iptables -L
and
iptables -t nat -L
answered Oct 4 '10 at 14:13
RichmRichm
3,1641612
I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?
– Patrick
Oct 4 '10 at 14:35
1
"man iptables" is your friend :-)
– Richm
Oct 4 '10 at 14:53
1
But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.
– Richm
Oct 4 '10 at 14:56
@Richm: Well whaddayaknow.iptables -P FORWARD ACCEPTmade the magic happen.. Now I just need to figure out how I can set this to LAN only..
– Patrick
Oct 4 '10 at 15:47
1
The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.
– Richm
Oct 4 '10 at 16:52
|
show 1 more comment
Is the firewall on the server disabled? It maybe that there are some firewall rules that are blocking the packets. Look at the output of iptables (must be run as root) and if you see anything other than ACCEPT rules/policies then they may be blocking things.
iptables -L
and
iptables -t nat -L
answered Oct 4 '10 at 14:13
RichmRichm
3,1641612
I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?
– Patrick
Oct 4 '10 at 14:35
1
"man iptables" is your friend :-)
– Richm
Oct 4 '10 at 14:53
1
But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.
– Richm
Oct 4 '10 at 14:56
@Richm: Well whaddayaknow.iptables -P FORWARD ACCEPTmade the magic happen.. Now I just need to figure out how I can set this to LAN only..
– Patrick
Oct 4 '10 at 15:47
1
The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.
– Richm
Oct 4 '10 at 16:52
|
show 1 more comment
Is the firewall on the server disabled? It maybe that there are some firewall rules that are blocking the packets. Look at the output of iptables (must be run as root) and if you see anything other than ACCEPT rules/policies then they may be blocking things.
iptables -L
and
iptables -t nat -L
answered Oct 4 '10 at 14:13
RichmRichm
3,1641612
Is the firewall on the server disabled? It maybe that there are some firewall rules that are blocking the packets. Look at the output of iptables (must be run as root) and if you see anything other than ACCEPT rules/policies then they may be blocking things.
iptables -L
and
iptables -t nat -L
answered Oct 4 '10 at 14:13
RichmRichm
3,1641612
answered Oct 4 '10 at 14:13
RichmRichm
3,1641612
answered Oct 4 '10 at 14:13
RichmRichm
3,1641612
answered Oct 4 '10 at 14:13
RichmRichm
3,1641612
3,1641612
I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?
– Patrick
Oct 4 '10 at 14:35
1
"man iptables" is your friend :-)
– Richm
Oct 4 '10 at 14:53
1
But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.
– Richm
Oct 4 '10 at 14:56
@Richm: Well whaddayaknow.iptables -P FORWARD ACCEPTmade the magic happen.. Now I just need to figure out how I can set this to LAN only..
– Patrick
Oct 4 '10 at 15:47
1
The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.
– Richm
Oct 4 '10 at 16:52
|
show 1 more comment
I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?
– Patrick
Oct 4 '10 at 14:35
1
"man iptables" is your friend :-)
– Richm
Oct 4 '10 at 14:53
1
But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.
– Richm
Oct 4 '10 at 14:56
@Richm: Well whaddayaknow.iptables -P FORWARD ACCEPTmade the magic happen.. Now I just need to figure out how I can set this to LAN only..
– Patrick
Oct 4 '10 at 15:47
1
The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.
– Richm
Oct 4 '10 at 16:52
I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?
– Patrick
Oct 4 '10 at 14:35
I figured it had something to do with the firewall. I'm using Jay's Iptables Firewall (yes, its not maintained, I know) since I never put myself trough learning iptables. This results in quite a few rules, but as far as I can see all "LAN rules" are allowed (the top LAN rules have ACCEPT in them). Is there any way I can "clear" the iptables to test whether or not it's the iptable rules that are the villain here?
– Patrick
Oct 4 '10 at 14:35
1
1
"man iptables" is your friend :-)
– Richm
Oct 4 '10 at 14:53
"man iptables" is your friend :-)
– Richm
Oct 4 '10 at 14:53
1
1
But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.
– Richm
Oct 4 '10 at 14:56
But in any case try iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F INPUT; iptables -F OUTPUT; iptables -F FORWARD; You may also need to do the same with the nat tables but you should be able to work out what is needed there from the examples above.
– Richm
Oct 4 '10 at 14:56
@Richm: Well whaddayaknow.
iptables -P FORWARD ACCEPT made the magic happen.. Now I just need to figure out how I can set this to LAN only..– Patrick
Oct 4 '10 at 15:47
@Richm: Well whaddayaknow.
iptables -P FORWARD ACCEPT made the magic happen.. Now I just need to figure out how I can set this to LAN only..– Patrick
Oct 4 '10 at 15:47
1
1
The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.
– Richm
Oct 4 '10 at 16:52
The behaviour of the bridging firewall code changed between the 2.4 and 2.6 kernel series. From memory 2.6.x will match the input against the br0 interface unless your iptables rules specify "-m physdev --physdev-in eth0" in which case it would match the physical input device. Of course you can swap eth0 for eth1 and --physdev-in for --physdev-out as appropriate.
– Richm
Oct 4 '10 at 16:52
|
show 1 more comment
If the two devices cannot ping each other it sounds like the bridge is not correctly setup. There is no ip protocol routing involved in the bridge. What is the output of brctl show ? That should show something like
$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.003018a46079 no eth1
eth2
If both interfaces are not listed there then that needs correcting.
You may also like to try the brctl showmacs br0 command and if STP (spanning tree protocol) was enabled above the brctl showstp br0 command. The former should show the mac addresses of the two devices and the for the latter you should look to make sure that each port is in state forwarding
Given that you say that each can access the internet I assume that all of the interfaces have been brought up. If not the following should do that.
ip link set br0 up
ip link set eth0 up
ip link set eth1 up
ip link set eth2 up
answered Oct 4 '10 at 11:34
RichmRichm
3,1641612
brctl showdisplays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed byip a show.
– Patrick
Oct 4 '10 at 12:46
add a comment |
If the two devices cannot ping each other it sounds like the bridge is not correctly setup. There is no ip protocol routing involved in the bridge. What is the output of brctl show ? That should show something like
$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.003018a46079 no eth1
eth2
If both interfaces are not listed there then that needs correcting.
You may also like to try the brctl showmacs br0 command and if STP (spanning tree protocol) was enabled above the brctl showstp br0 command. The former should show the mac addresses of the two devices and the for the latter you should look to make sure that each port is in state forwarding
Given that you say that each can access the internet I assume that all of the interfaces have been brought up. If not the following should do that.
ip link set br0 up
ip link set eth0 up
ip link set eth1 up
ip link set eth2 up
answered Oct 4 '10 at 11:34
RichmRichm
3,1641612
brctl showdisplays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed byip a show.
– Patrick
Oct 4 '10 at 12:46
add a comment |
If the two devices cannot ping each other it sounds like the bridge is not correctly setup. There is no ip protocol routing involved in the bridge. What is the output of brctl show ? That should show something like
$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.003018a46079 no eth1
eth2
If both interfaces are not listed there then that needs correcting.
You may also like to try the brctl showmacs br0 command and if STP (spanning tree protocol) was enabled above the brctl showstp br0 command. The former should show the mac addresses of the two devices and the for the latter you should look to make sure that each port is in state forwarding
Given that you say that each can access the internet I assume that all of the interfaces have been brought up. If not the following should do that.
ip link set br0 up
ip link set eth0 up
ip link set eth1 up
ip link set eth2 up
answered Oct 4 '10 at 11:34
RichmRichm
3,1641612
If the two devices cannot ping each other it sounds like the bridge is not correctly setup. There is no ip protocol routing involved in the bridge. What is the output of brctl show ? That should show something like
$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.003018a46079 no eth1
eth2
If both interfaces are not listed there then that needs correcting.
You may also like to try the brctl showmacs br0 command and if STP (spanning tree protocol) was enabled above the brctl showstp br0 command. The former should show the mac addresses of the two devices and the for the latter you should look to make sure that each port is in state forwarding
Given that you say that each can access the internet I assume that all of the interfaces have been brought up. If not the following should do that.
ip link set br0 up
ip link set eth0 up
ip link set eth1 up
ip link set eth2 up
answered Oct 4 '10 at 11:34
RichmRichm
3,1641612
answered Oct 4 '10 at 11:34
RichmRichm
3,1641612
answered Oct 4 '10 at 11:34
RichmRichm
3,1641612
answered Oct 4 '10 at 11:34
RichmRichm
3,1641612
3,1641612
brctl showdisplays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed byip a show.
– Patrick
Oct 4 '10 at 12:46
add a comment |
brctl showdisplays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed byip a show.
– Patrick
Oct 4 '10 at 12:46
brctl show displays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed by ip a show.– Patrick
Oct 4 '10 at 12:46
brctl show displays the same as your output (with change in bridge id of course). showmacs displays the mac addresses of my clients and my connected interfaces, all four of them. All interfaces are up as displayed by ip a show.– Patrick
Oct 4 '10 at 12:46
add a comment |
Check if ip fowarding is enabled on the server with the command
sysctl net.ipv4.ip_forward
if this gives 0, do
sysctl -w net.ipv4.ip_forward=1
as root on the server. If this helps, make the change permanent by editing /etc/sysctl.conf
answered Oct 4 '10 at 10:52
fschmittfschmitt
7,6713043
it printsnet.ipv4.ip_forward = 1, so no dice unfortunately.
– Patrick
Oct 4 '10 at 10:58
add a comment |
Check if ip fowarding is enabled on the server with the command
sysctl net.ipv4.ip_forward
if this gives 0, do
sysctl -w net.ipv4.ip_forward=1
as root on the server. If this helps, make the change permanent by editing /etc/sysctl.conf
answered Oct 4 '10 at 10:52
fschmittfschmitt
7,6713043
it printsnet.ipv4.ip_forward = 1, so no dice unfortunately.
– Patrick
Oct 4 '10 at 10:58
add a comment |
Check if ip fowarding is enabled on the server with the command
sysctl net.ipv4.ip_forward
if this gives 0, do
sysctl -w net.ipv4.ip_forward=1
as root on the server. If this helps, make the change permanent by editing /etc/sysctl.conf
answered Oct 4 '10 at 10:52
fschmittfschmitt
7,6713043
Check if ip fowarding is enabled on the server with the command
sysctl net.ipv4.ip_forward
if this gives 0, do
sysctl -w net.ipv4.ip_forward=1
as root on the server. If this helps, make the change permanent by editing /etc/sysctl.conf
answered Oct 4 '10 at 10:52
fschmittfschmitt
7,6713043
answered Oct 4 '10 at 10:52
fschmittfschmitt
7,6713043
answered Oct 4 '10 at 10:52
fschmittfschmitt
7,6713043
answered Oct 4 '10 at 10:52
fschmittfschmitt
7,6713043
7,6713043
it printsnet.ipv4.ip_forward = 1, so no dice unfortunately.
– Patrick
Oct 4 '10 at 10:58
add a comment |
it printsnet.ipv4.ip_forward = 1, so no dice unfortunately.
– Patrick
Oct 4 '10 at 10:58
it prints
net.ipv4.ip_forward = 1, so no dice unfortunately.– Patrick
Oct 4 '10 at 10:58
it prints
net.ipv4.ip_forward = 1, so no dice unfortunately.– Patrick
Oct 4 '10 at 10:58
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%2f2696%2fusing-bridge-utils-to-connect-two-computers-via-linux%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
