Your local network is 192.168.1.0/24, as shown by this line in your routing table:
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.32 metric 1
Your VPN network is 10.0.0.0/8, as shown by this line:
10.0.0.0/8 dev tun0 scope link
Currently, your default router is:
default via 192.168.1.254 dev eth0 proto static
which is of course what you do not want, because it belongs to your local LAN: thus all of your stuff is routed through your local gateway, as if the VPN did not exist.
You do have however, the all-important statement
128.122.252.68 via 192.168.1.254 dev eth0 src 192.168.1.32
which is the route to your VPN-provider.
EDIT:
I had not realized that the routing table is simply the one that is obtained from your VPN, without your intervention. This may indicate (indirectly) that your service provider is willing to forward only the traffic explicitly allowed in your table through the interface tun0, and may have taken further steps to block all other traffic, in which case your efforts will be futile.
However, assuming that your provider is willing to forward all of your traffic, what you need to do is the following.
First, you need to find out whether there is a gateway willing to accept your connection on the other side, because we need its IP address. I will give you four methods to do this.
1) With the pc connected to the VPN, try the following command:
sudo dhclient -v tun0
If everything goes well, you should see a reply containing this line:
DHCPOFFER of a.b.c.d from x.y.w.z
x.y.w.z is the IP address of the local gateway. You may have to shutdown your VPN after this test, and maybe even to reboot your pc, because we will have just messed up the routing table pretty well.
2) Alternatively, you may try navigating to one of the allowed sites (those that appear in your routing table as going through the tun0 interface), then issuing the command:
ip neigh show
You should get a list of pcs contacted through the ARP protocol, with MAC and IP address; most likely, you will receive either zero or one reply. If you get a single reply, then that's your router.
3) If you get no such reply, then you may try with
sudo nmap -sn 10.0.0.0/8
(which is going to be very slow). Your gateway will be one of the pcs listed, most likely the one with address ending in .1 or in .254, if any such exist.
4) Use the tcpdump command:
sudo tcpdump -n -i tun0
and see the IP addresses spewed out by the command.
If you get no proper reply to this test either, it means someone has really tightened the screws in his network.
But let us be optimistic, and suppose you now have a candidate IP address x.w.y.z for the remote router. You will need to delete the default gateway, (as sudo!):
ip route del default via 192.168.1.254
an add the new one:
ip route add default via x.w.y.z
and try to navigate.
Let me repeat: since your provider has allowed traffic only to a few selected IP addresses through his VPN, it is possible he may have taken extra measures (=firewall) to prevent a smart user to force his generic traffic through his VPN. In this case, there is nothing you can do. But if he did not, the above steps should help you find a solution.
Given that ssh works but telnet doesn't, there are a few options:
- A firewall is blocking the traffic on the server
- Telnet is not running on the server
- Your connections are routed through a gateway that filters out telnet traffic
- You typed different ip addresses when you tried to connect via ssh / telnet
1. It could be your server's firewall that's blocking the connection.
As a quick check, add (temporary) rules to allow all the traffic:
[root@server]# iptables -I INPUT 1 -j ACCEPT
[root@server]# iptables -I OUTPUT 1 -j ACCEPT
You might as well do the same on the client to get that out of the way.
When you're done testing (at the end of this message), remove these two with
[root@server]# iptables -D INPUT 1
[root@server]# iptables -D OUTPUT 1
2. Your server is missing a route for its 192.18.209.0/24 (?) subnet
Your server's routing table is weird. You said its IP address was 192.18.209.124, but the routing table says it's 192.18.212.124 . Did you change it to the 212 subnet to test some things? If so, can you revert it back to the state it was when you wrote your first message?
Do traceroutes from the server to the client and vice versa to check the paths are correct.
3. Full testing sequence, ONLY if you have a physical access to the server (as you might lose network access due to the potential ip change)
Assuming your topology is a very simple one with both machines on the same network as on the following diagram:
+---------+ Server: 192.18.209.124/24
| Switch | CentOS: 192.18.209.87 /24
+---------+
_____| |_____
| |
+--------+ +--------+
| Server | | CentOS |
+--------+ +--------+
[root@server] iptables -I INPUT 1 -j ACCEPT
[root@server] iptables -I OUTPUT 1 -j ACCEPT
[root@server] ifconfig eth2 192.18.209.124/24
[root@server] netstat -tapn | grep :23
[root@centos] iptables -I INPUT 1 -j ACCEPT
[root@centos] iptables -I OUTPUT 1 -j ACCEPT
[root@centos] traceroute 192.18.209.124
[root@centos] nc -vv 192.18.209.124 23
[root@server] traceroute 192.18.209.87
[root@server] iptables -D INPUT 1
[root@server] iptables -D OUTPUT 1
[root@centos] iptables -D INPUT 1
[root@centos] iptables -D OUTPUT 1
Best Answer
Bridging doesn't work the way you think it works. :-)
A bridge is only concerned with OSI level 2 (Ethernet frames). On this level, IP addresses etc. don't exist. Conceptually, you can think of a bridge as a collection of ethernet interfaces. Each interface is called a port, and a packet that goes into one port comes out on all other ports. (Actually, in the Linux implementation, there's an optimization that keeps a table of seen MAC addresses, but conceptually, it doesn't matter).
So a bridge can connect ("bridge") several ethernet segments into one big segment.
Then what does it mean to "give a Linux bridge an IP address"? In the Linux implementation, the bridge is not a separate hardware device (like they originally were), it's also accessible from the host itself. That means it acts like a kind of "super-ethernet interface" with many ports, but packets that go into the kernel or out from this kernel to or from any of these ports reach the Linux OS under a single IP address.
So as soon as you make an ethernet interface a slave (port) of a bridge, it ceases to have its own address. The only thing that counts is the IP address of the bridge.
In other words, making a bridge with only a single port makes no sense (you could have used the interface by itself). Trying to route packets to a port of a bridge makes no sense (as far as the kernel is concerned, the bridge is a single device).
If you want to play around with a bridge, you need a structure like this:
Here the left segment with hosts A and B is bridged by host X to the right segment with hosts C and D, and each host is accessible by a single IP address (which is assigned to interfaces or the bridge as a whole).