Re: Freeswan (CentOS 4.5)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Howard Wilkinson wrote:
tony.chamberlain@xxxxxxxxx wrote:


Has anyone had experience with Freeswan?

We have a situation where say there is a Linux machine in City 1 with IP address 10.0.0.10 (for example) and a Linux machine in City 2 with an IP address of 10.0.0.20 (for example). Now these machines are in different cities, so machine 1 cannot just open a socket on 10.0.0.20 because machine 2 is on a different network. Each machine does have a router, say City 1 is 65.15.47.28 (for example). To get into City 1from outside the network you go through thr router, use 65.15.47.28 which routes into the LAN. The same for City 2. For a unix process on 10.0.0.10 to send to 10.0.0.20 it would have to send to 65.15.47.28 which would route it in. Problem is, its from address would be 10.0.0.10, which the machine at 10.0.0.20 wouldn't know about.
A process on 10.0.0.20 would have to do something similar to respond.

Now these machines have to actually be able to use each others' 10.0.0.X addresses. I assume this is possible via a VPN. They don't have any Cicsco VPNs or anything, and they asked whether it is possible just using Linux (CentOS) to set up a VPN. I did a bit of searching and found a couple things. Freeswan seemed to be
the most promising, though other packages could be just as good.

Is the above scenario possible with Freeswan or can you recommend some other way?

it doesnt particularly matter what vpn transport you choose to go with, because in the end, you technically have "the same network" at both ends: 10.0.0.x.

for this to work right, you really need to re-ip one city to be 10.0.1.x. right now, if 10.0.0.10 tried to connect to 10.0.0.20, as it starts the connection, it compares the destination address to its own network settings and "oh, this must be local", and polls the local arp table accordingly.

the trick for 10.0.0.10 to access 10.0.0.20, will be to cause the "local lan" behavior to be overridden by behavior that causes 10.0.0.10 to hand the connection off to the router. a static route could be one way:

route add 10.0.0.20 netmask 255.255.255.0 gw 10.0.0.1 eth0

the above statement would cause .20 to be routed thru the defaultgateway of .1 (for the example i just make an assumption that .1 is your default gateway...), but .10 would continue to use "local lan behavior" to access any other host that falls under 10.0.0.x. you would need to reverse the behavior for the .20 at the other location to access the .10.

if these are the single sole computers that exist at both ends, then the route statement is simple enough to get you going. as soon as the same ip exists on a machine at both ends, your asking for a giant can of worms, and it wouldnt be worth the trouble. at that point, you need to bite the bullet and re-ip one location, and then it would be as simple as "just let the vpn-firewalls do their job".

hope this helps,
--
Jonathan Horne
http://dfwlpiki.dfwlp.org
linux08 _@_ dfwlp.com

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux