Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I have a system with 2 interfaces eth0, and eth1.
eth0 is 192.168.0.250 and connected to gateway 192.168.0.2.
eth1 is connected to 192.123.123.10 via a swtich.
I am trying to route packets from 192.123.123.10 to gateway 192.168.0.2, which means I need to route 192.123.123.x packets coming into eth1 interface out via eth0 interface.
I set ip_forward file to 1.
I ran this command:
route add -net 192.123.0.0 netmask 255.255.255.0 dev eth0
route add default gw 192.168.0.2
I can ping from 129.123.123.10 to 192.168.0.250, but I can't ping to 192.168.0.2
I think the packets are not being forwarded to eth0.
My routing table looks something like this:
gteway Genmask Flags Ref Iface
192.123.123.0 * 255.255.255.0 U eth1
192.168.0.0 * 255.255.255.0 U eth0
192.123.0.0 * 255.255.255.0 U eth0
default 192.168.0.2 0.0.0.0 UG eth0
Can anyone tell me what is missing?
Thank you in advance.
You are missing your back path route.
The host 192.168.0.2 see packet coming from 192.123.123.10 but he doesn't know how to route the reply packet back since it doesn't have the return route.
You can do two things:
1- create a route on 192.168.0.2 machine to handle traffic directed to 192.123.123.0/24
2- NAT on your 192.168.0.250 host with the command below:
iptables -t nat -A POSTROUTING -s 129.123.123.0/24 -j SNAT --to-source 192.168.0.250
It's not your routing table on this system that you need to be concerned about. It's the routing tables of the other systems. 192.168.0.2 knows nothing about the 192.123.X.X network being routed to 192.168.0.250. Similarly the hosts on 192.123.X.X need to route the 192.168.X.X network over to 192.123.123.10.
I'm fairly certain this can be achieved using iptables and port forwarding rules. There is some more information here http://www.revsys.com/writings/quicktips/nat.html about how to forward packets between interfaces.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
hello family first i show you my topology
topology
I have 4 frame relay switchs.
Frame-relay-switch1switch1
Frame-relay-switch2switch2
Frame-relay-switch3switch3
Frame-relay-switch4switch4
here is the configuration of the routers
router1
no ip address
encapsulation frame-relay
serial restart-delay 0!
interface Serial1/0.1 multipoint
ip address 192.168.1.1 255.255.255.0
snmp trap link-status
frame-relay map ip 192.168.1.3 102 broadcast
frame-relay map ip 192.168.1.2 101 broadcast
frame-relay interface-dlci 101
router2
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0!
interface Serial1/0.1 point-to-point
ip address 192.168.1.2 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 103
router 3
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0!
interface Serial1/0.1 point-to-point
ip address 192.168.1.3 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 101
the link between router 1 and router 2 is working but between router 1 and router 3 is not working
and i don't know why !!! help me please
hello Tang Li try this topology I hope it will help you
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
I use NetworkManager to connect to VPN servers. My VPN has multiple servers, so I configured a dozen or so profiles. NetworkManager allows you to connect to multiple VPNs at once; if I do this, the routing table can end up with multiple default routes.
What does Linux do in this situation?
Is there any way to configure it so that it'll pick faster gateways?
Example (partial table):
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.8.1 0.0.0.0 UG 50 0 0 tun0
0.0.0.0 10.7.7.1 0.0.0.0 UG 51 0 0 tun1
0.0.0.0 10.8.8.1 0.0.0.0 UG 52 0 0 tun2
0.0.0.0 10.7.7.1 0.0.0.0 UG 53 0 0 tun3
0.0.0.0 10.8.8.1 0.0.0.0 UG 54 0 0 tun4
0.0.0.0 192.168.50.1 0.0.0.0 UG 100 0 0 enp0s31f6
Your extra gateways have different metric (and possibly have different tables, post ip rule show and ip route list table TTT where TTT are all tables mentioned by ip rule show). Metric is documented in man 8 route http://man7.org/linux/man-pages/man8/route.8.html
metric M
set the metric field in the routing table (used by routing
daemons) to M. If this option is not specified the metric for
inet6 (IPv6) address family defaults to '1', for inet (IPv4)
it defaults to '0'. You should always specify an explicit
metric value to not rely on those defaults - they also differ
from iproute2.
Metric The 'distance' to the target (usually counted in hops).
Rules are https://serverfault.com/questions/648276/routing-selection-specificity-vs-metric:
Single routing table... In this case, the kernel chooses:
the most specific route;
if there are multiple equally specific routes, the one with the smallest kernel metric.
So, when there are no multiple routing tables, linux will use only one reachable gateway with lowest metric (it probably will not use gateway from offline network interface).
Is there any way to configure it so that it'll pick faster gateways?
No, when the gateway is not used, you can't check how fast it is. Also you can't afford personal computer to have own AS to legally have several gateways which can connect your single IP to the internet. (So, picking different gateway will break all your TCP and UDP connections, as you will use different IP address in the internet).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
In Lab we have two hosts say A and B.
host A has two NIC and host B has single NIC (see below diagram for network topology)
NIC-1 of host A is connected to lab network and
NIC-2 of host A is connected directly (end-to-end) to host B
----------
| | -> NIC1 ------> Lab Network (10.203.194.0/24)
| | (eth0 - 10.203.194.247/24)
| host A | ----------
| | -> NIC2 -------> NIC1 | host B |
----------- (eth1 - 10.203.209.230/24) -----------
(eth0 - 10.203.194.163/24)
From host A, I was able to ping 'lab network' whereas I couldn't connect/ping host B (10.203.194.163). I find a routing table of host A has default gw to lab network.
What changes were required to connect Lab network and host B FROM host A.
I can go for a bridge connection connecting both eth0 and eth1 interface in host A; but I don't prefer that option because host B should not recieve any packet specific to lab network and that is the reason I did not connect host B directly to lab network.
I am looking for some routing option that is specific to the destination/source and the interface has to be decided based on that.
Finally, I was able to resolve the issue by simply adding the rule in the route table.
$>route add –host 10.203.194.163 dev eth1
and now my routing table looks like:
Destination Gateway Genmask Flags MSS Windows irtt Iface
10.203.194.163 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
10.203.194.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 10.203.194.1 0.0.0.0 UG 0 0 0 eth0
and when I ping from host B to host A and running tcpdump on eth0, I won't get any ICMP packets and in eth1 I can see all ICMP packets from host B :)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
Could you please explain the following basic ip routing table:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.80.0.0 192.176.20.1 255.255.255.0 UG 0 0 0 eth0
192.176.100.0 * 255.255.255.0 U 0 0 0 int1
10.1.1.0 192.176.20.1 255.255.255.0 UG 0 0 0 eth0
10.13.1.0 192.176.100.1 255.255.255.0 UG 0 0 0 int1
192.176.0.0 * 255.255.0.0 U 1 0 0 eth0
default 192.176.20.2 0.0.0.0 UG 0 0 0 eth0
Well you have 2 local interfaces on the router; eth0 and int1. I guess it's easiest to go through line by line of the routing table.
Destination Gateway Genmask Flags Metric Ref Use Iface
10.80.0.0 192.176.20.1 255.255.255.0 UG 0 0 0 eth0
This states that any packet with a destination of 10.80.0.0/24 will be sent out eth0 using a gateway of 192.176.20.1.
Destination Gateway Genmask Flags Metric Ref Use Iface
192.176.100.0 * 255.255.255.0 U 0 0 0 int1
This states that any packet with a destination of 192.176.100.0/24 will be sent out int1 without using a gateway.
Destination Gateway Genmask Flags Metric Ref Use Iface
10.1.1.0 192.176.20.1 255.255.255.0 UG 0 0 0 eth0
This states that any packet with a destination of 10.1.1.0/24 will be sent out eth0 using a gateway of 192.176.20.1.
Destination Gateway Genmask Flags Metric Ref Use Iface
10.13.1.0 192.176.100.1 255.255.255.0 UG 0 0 0 int1
This states that any packet with a destination of 10.13.1.0/24 will be sent out int1 using a gateway of 192.176.100.1.
Destination Gateway Genmask Flags Metric Ref Use Iface
192.176.0.0 * 255.255.0.0 U 1 0 0 eth0
This states that any packet with a destination of 192.176.0.0/16 will be sent out eth0 without using a gateway.
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.176.20.2 0.0.0.0 UG 0 0 0 eth0
This states that any packet that doesn't match any of the above routes will be forwarded out eth0 with a gateway of 192.176.20.2. Most likely a route to the internet (also called Gateway of Last Resort, if I'm not mistaken).
If you need more information, don't hesitate to ask.
Extra info on the specifics: http://www.cyberciti.biz/faq/what-is-a-routing-table/
Destination = the address of the network that the packet is headed to
The "default" means that if the destination is not found in any of the other rules, than use this rule.
Genmask = The subnet mask
If there is more than one address in the routing table that works for the outgoing packet, the rule with the higher subnet mask will be used. If those are tied, then metric comes into play but that will be different based on what protocol is being used.
Interface = On-board connection
For example, the laptop I am on currently has three interfaces:
Ethernet card
Wireless card
Bluetooth
Routers generally have at least 2 interfaces for each side, 1 for each network they are a part of. For most home routers, 1 interface is part of your home network and the other is part of the external network (usually the internet) headed toward your ISP.
Gateway = Next hop
This is where the packet will be sent if the destination is not on the same network as the sender.
If the value is "*" or "On-link" or the address of the current device... these all mean the same thing. It means that the packet is addressed to a device that is directly reachable by the current host. In other words, they're on the same network so the gateway won't actually be used because the host will know the data link layer (MAC) address of the destination and be able to send it directly there. These values are just used for human readability in this case.
As for the process of sending a packet:
Destination and Genmask are used to figure out which rules are a
match for the destination address of the outgoing packet.
Interface is used to decide what communication device on the machine
to send it through.
Gateway is the address of the device on the same network that it will
send the packet to.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
for my problem I searched a lot but did not find a feasible solution, so I thought to my self to place a question in here.
The problem:
I have a remote server (lets call it A) and a local computer (lets
call it B), both running Ubuntu 14.04. I could establish a reversed
SSH tunnel connecting A and B by doing so At server A: ssh -R
2014:localhost:22 userb#B At the local computer B: ssh -p 2014
usera#localhost
where user-a and user-b are two users at A and B, respectively.
Now, I connect A to a VPN. After the VPN connection is successfully
established, the currently openning ssh session does not respond
anymore. Also, I cannot ssh into A anymore until after I killed the
VPN connection.
Is there a way to let both SSH and VPN be happy? Perhaps to separate the SSH session from VPN ? (I found something called split tunneling but did not really understand it). Could someone enlightens me on this?
This may be a bit late, but ...
The problem is that the default gateway gets changed by OpenVPN, and that breaks your current SSH connection unless you set up appropriate routes before you start OpenVPN.
What follows works for me. It uses iptables and ip (iproute2). Below, it is assumed that the default gateway interface before OpenVPN is started is "eth0". The idea is to ensure that when a connection to eth0 is made, even if eth0 is not the default gateway interface anymore, response packets for the connection go back on eth0 again.
You could use the same number for the connection mark, firewall mark and routing table. I used distinct numbers to make the diffences between them more apparent.
# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412
# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412
===
UPDATE:
The above works fine for me on Debian Jessie. But on an older Wheezy system I have just found that I need to add "via" to the routing table entry:
# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412
There "12.345.67.89" must be the original non-VPN gateway.
VPN screws up your route table by modifying your default gateway toward the new tunnel interface. The funny thing is that you can't initiate a new ssh connection afterward.
So you are saying that ssh -R 2014:localhost:22 userb#B wouldn't connect when going through your VPN?
What is traceroute saying? (Once VPN loaded). Don't you have any kind of port limitation with your vpn provider? If you are using a commercial one I mean.
--- EDIT
Your best try would be, while connected to VPN, from server A :
telnet B 22
To see if you can make a simple TCP SYN to destination. Anyway I'd be surprised hidemyass wouldn't let your ssh traffic going through.
To recap, your VPN is configured on your server?
You are trying to connect from your server B to your client A, through your VPN?
You should be able to traceroute to your VPN public address (which you can get with whatismyip.com for example).
You could check as well on your client for remote packets, coming from your server :
tcpdump -nnXs 0 -i eth0 host ip.of.vpn