hello everyone,
i am reading alot lately about iptables: natting and port ffwding. and i have come to realise things are quite messed up in my head..
so i would like some pointers to clarify the scope of use of the 'route' command... i mean it routes packets to other networks/interfaces or default gws... but isn't that what you do from 'iptables' NAT table too?

and what is the purpose of the 'ip' command? is it overlapping with that of 'route' at all?

im stuck at reading endless guides but im nowhere close to being able to comprehending everything...



here is the practical situation that led me to start reading about all that..

i have an openvpn server at home, running 2 daemons. one is on udp port 1194 and the other is on tcp port 443... i need both currently for reasons i wont go into now. the udp vpn subnet is the 192.168.144.0 and the tcp one is 192.168.145.0.. they both are set up for routing, rather than bridging (so they both use tun ifaces..

openvpn documentation has a guide so that machines on the vpn subnet can 'see' machines on the server's side LAN.. i extended that thought to include the other vpn subnet... http://openvpn.net/index.php/documen...wto.html#scope

so basically from the 192.168.145.0 openvpn server config file i added the ability to 'see' the other 2 subnets, ie the server local subnet 192.168.0.0 and the other vpn subnet 192.168.144.0... as:

but i can not ping another machine on the vpn side... in neither of the subnets...
EDIT: looking into it further if i add the above 2 'push' commands to the server.conf, the client will try to route add these -nets , along with a new default gw... as a result i lose internet connectivity altogether from then on...

additionally, the openvpn documentation states i can route all client traffic through the openvpn server: http://openvpn.net/index.php/documen....html#redirect
but i need to do more than just add the statement
dont i?

however couldn't i just add a route on the client? would that work?
do i have to carry out any additional steps to get firefox working on my ubuntu laptop after the vpn have been connected, like add a proxy route, or should i just leave it to 'directly connected to the internet' ?

i hope im not too confusing in the process of being confused myself...
thank you for any pointers and help in advance.
nass

There are several things going on here at once; perhaps some classification is in order:

1. At the most basic level, your Linux box routes packets that arrive there, but are not destined for itself. This means that when it receives a packet not addressed to one of its IP addresses, it looks in the route table to figure out which of its interfaces the packet should be forwarded to.

The route command allows you to add or delete entries in this table; the ip route command is an extension of this same function. Historically, route was the only command available; the ip command set tries to consolidate several operations into one command.

2. You are using Private Networking addresses (192.168.x.x). These are both a good and a bad thing: the good part is that you do not need anyone's permission or cooperation to use them (since they are private); the bad part is that you need to take steps to make sure that packets containing these addresses do not escape onto the public Internet (because they are private). Any public Internet router will drop such a packet unceremoniously, disrupting the attempted communication.

The usual way that you can arrange communication between machines on your private LAN and ones on the public Internet is by using Network Address Translation (NAT). This process runs on a boundary machine (one that has one foot on your LAN and one in the public Internet), and works by collecting outbound packets from your private LAN, altering them so that they appear to come from itself, and sending them out onto the public Internet. When the replies arrive, it undoes this alteration, and forwards the reply onto the LAN, so that the originator gets the reply it is waiting for. This works fine for conversations originating with one of your private LAN machines, but does not work for conversations originating out in the Internet.

3. On top of these two things, your OpenVPN sets up a channel between two different nets, usually separated by some public Internet connectivity, and can be configured so that machines on either end can converse with machines on the opposite side. Along the way, OpenVPN encrypts and decrypts the packets as they transit the public Internet, to protect them from prying eyes.

If you want to make all machines on one private net accessible from all machines on the second, what you really want is a symmetric VPN tunnel between them. Unfortunately, terminology and network protocols get in the way of seeing this. In order to establish the tunnel, one side has to start, and the other has to just listen for a connect attempt. The server is the one that listens, and the client is the one that starts. After that, the two ends should behave more or less the same: as packets arrive destined for the other end, they are received by the OpenVPN server attached to the local net, encrypted, encapsulated, and sent over a private connection between the servers, where they are received, decrypted, and forwarded out onto the private net at the other end.

In order for the OS to route packets to the OpenVPN server, a route must be established on the machines at each end of the VPN tunnel, specifying that addresses for the VPN subnet should be routed to the tun interface. This can be done in at least three ways: using the route command, the ip route command option, or using the OpenVPN configuration options. I would recommend that you do not use the OpenVPN push command to transfer route information between systems unless you really have to: it is safer to configure each end of the connection separately, and it also makes it easier to understand what is happening.

I hope this helps make sense of this thicket of info. Once you have the basics working, if you have more problems, please post again.

well i think im slowly getting the drift here...
i did go ahead and manually set up routes on separate computers and verified its working..
im curious though y it wouldnt work with the openvpn 'push' command... and why you suggested not to use 'push'...

apart from that i also tried making the linux home server machine, the default gateway for the internal home network...up until now the router used to be the default gw on all machines.

so in the beginning some things would not work, and i went on to add the following rule in the forward chain:

since im been more than 12h in front of the pc i want to know if this is a stupid and perhaps unsafe rule.. or is it perfectly ok..
thank you for your help
nass

If $INET_IFACE is your local net interface, it is probably safe to use that forwarding rule, since I assume that you basically trust the machines that are on your local net. I cannot see why you would want to do this, though, if $INET_IFACE is the connection to the public Internet.

My reasoning to avoid "push" is that its use complicates the analysis. This command is really intended for a more traditional client-server scenario (the example that the OpenVPN site uses is that of a "road warrior" with a laptop connecting to a corporate net). If the VPN is essentially asymmetric, then it makes some sense for the server to "push" routing info onto the client machine, who is presumably too ill-informed to take care of this himself. But in your case, where there are two independent boundary machines, it seemed to me more understandable to have each machine configured to handle its end of the VPN without interference from the other end.

the thing is i only have 1 NIC on the server currently..
so both internet and local traffic pass through it..

and to avoid ffwding the internet traffic, i added the -s rule...
i just don't know if something has slipped out of attention and could pose a potential threat to the pc...

I encourage you to beg, borrow or steal a second NIC for your boundary machine. It is *not safe* to have both public and private network traffic passing through the same interface. The problem is that, unless you force the same restrictions on your private network traffic that you would on traffic from the public Internet, your machine is open to attack by anyone on the public Internet. Just because the conventions say that Private Network addresses should not travel over the public Internet does not mean that everyone follows those rules. A source-routed packet could be generated anywhere in the world and addressed to your Private Network address; if your acceptance rules allow that packet into that interface, you could be attacked from the blind side.

Indeed you are correct. However, currently this server is not a boundary machine. There is a linksys modem/router in the internet end to my home. Gradually however this server will become the routes and internet gateway so i started pointing the gateway of the internal network pcs to the server machine. And since not all services were working, i realised i had to allow forwarding of local packets.