[prev in list] [next in list] [prev in thread] [next in thread]
List: ipcop-user
Subject: Re: [IPCop-user] VPN Connection Problems after move
From: Eric Shubert <ejs () shubes ! net>
Date: 2010-06-24 1:10:56
Message-ID: hvubb1$fij$1 () dough ! gmane ! org
[Download RAW message or body]
G.W. Haywood wrote:
> Hi there,
>
> On Tue, 22 Jun 2010 Eric Shubert wrote:
>
>> Once again, I'm trying to connect an OpenVPN client on the green subnet
>> to a second IPCop host that's sitting on the primary IPCop's orange
>> network. When the second IPCop is on the primary IPCop's green network,
>> the VPN works fine.
>
> Two things.
>
> 1. Each machine in the path from OpenVPN client to OpenVPN server AND
> BACK needs to know where to send the VPN packets. It does this by
> looking at its routing table. The table is a list of addresses or
> networks sorted from most specific (single IP/hostname) at the top
> through least specific (networks of incresing sizes) to the catch-
> all "default gateway" at the bottom. Looking up an address in the
> list is done by starting at the top of the list and working down it
> until there's a match. For example the list might have no entry
> which is exactly "192.168.10.22" but it might have one which is for
> the entire /24 network, "192.156.10.0/255.255.255.0". This means
> that when the kernel sees a packet which is to go to 192.168.10.22,
> it finds that entry in the table first and looks for the rest of the
> information in that record in the table. The list has an IP address
> for the next hop -- not the ultimate destination -- so for example it
> might say packets for 192.168.10.0/24 must go next to 192.168.0.1".
> This process repeats at each machine along the path from A to B via
> however many other machines there are in the path. The table needs
> to contain routes both for the VPN addresses and for 'real' ones. A
> route can refer to a 'real' interface or a virtual one.
>
> To create a routing table entry for this example you'd say something
> like "route add -net 192.168.10.0 netmask 255.255.255.0 gw 192.168.0.1"
> and you could see what effect that has had on the routing table with
> "route -n". If you just use "route" it will try to translate IPs to
> names. If your name server doesn't know the answers, things will be
> slow as it will keep on timing out.
>
> Here's the routing table for one of my machines at the moment:
>
> portakabin2:~$ >>> /sbin/route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 10.3.2.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
> 10.10.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
> 192.168.0.0 192.168.44.71 255.255.255.0 UG 0 0 0 eth0
> 192.168.44.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 192.168.12.0 192.168.44.71 255.255.255.0 UG 0 0 0 eth0
> 192.168.11.0 192.168.44.71 255.255.255.0 UG 0 0 0 eth0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
> 0.0.0.0 192.168.44.19 0.0.0.0 UG 1 0 0 eth0
>
> The interfaces tun0 and tun1 are virtual (OpenVPN) interfaces. This
> routing table tells the kernel that packets for HOST 10.3.2.2 go to tun0
> and packets for 10.10.0.2 go to tun1. Nothing at this end cares where
> the other ends of those tunnels are, as long as there are instances of
> OpenVPN there listening on the right ports. In fact one of those ends
> (connected to tun1) is just around the corner on the same industrial
> estate here in England, the other one (tun0) is 1,000 miles away in the
> south of France. There are two firewalls mentioned in this table. One
> is at 192.168.44.71. That is the firewall which protects the LAN at
> 192.168.44.0/24 from the other LANS connected to it (192.168.11.0/24,
> 192.168.11.0/24 and 192.168.0.0/24). Note that the routes for the the
> firewalls have the 'G' flag, they are gateways to other LANs. The other
> firewall is at 192.168.44.19, that's the firewall which is ultimately
> protecting the LAN from the Internet, and it's also the default gateway
> as it's the last route in the list. The network 0.0.0.0 matches when
> nothing earlier on in the table matched. Note that for packets going to
> 192.168.44.0/24 no gateway is needed, that's the network to which this
> machine is directly connected.
>
> When you understand a routing table which looks like this you should
> have no more troubles with routing. Take a little time to study it,
> ask any questions if you wish. Perhaps then we'll find out if I really
> understand it. :)
>
> 2. Each machine in the path also must PERMIT packets to pass through it,
> or to enter it, or to leave it. You use iptables to do that of course.
> For example to permit all packets to ORANGE through the firewall you
> might say "iptables -A CUSTOMFORWARD -d 192.168.10.0/24 -j ACCEPT" (if
> ORANGE is 192.168.10.0/24) but you'd also need to permit packets from
> GREEN with e.g. "iptables -A CUSTOMFORWARD -d 192.168.0.0/24 -j ACCEPT".
> You would probably want to make these rules tighter in practice. You'd
> need to do exactly the same kind of thing for your VPN IP addresses, as
> they won't be using the ORANGE or GREEN network addresses. If you have
> a VPN running you can more or less forget about the 'real' IP addresses
> and just work with the virtual ones. When you finally start to think
> about it in those terms it makes everything very much easier.
>
> I haven't mentioned setting up OpenVPN itself with the right IP addresses
> etc., I assume you have that all correct but it might benefit from checking.
> Why not post your configuration files, 'ifconfig' outputs and routing tables?
>
> --
>
> 73,
> Ged.
>
> ------------------------------------------------------------------------------
Ged,
Thank you so much for the very informative description.
I think my problem was in the area of #2. I didn't want/need to get into
iptables that deep at this time, so I decided to revert to my previous
setup, which is adequate, and within the stock configuration
capabilities of IPCop.
If I decide to try moving things around again at some point, I'll be
sure to reference your post.
Thanks again.
--
-Eric 'shubes'
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
IPCop-user mailing list
IPCop-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipcop-user
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic