> for testing with freeswan i have installed 4 UML-machines with following
> configuration:
>
> +-----------------------------+ +-----------------------------+
> |eth0 192.168.150.43 (tuntap)-----eth0 192.168.150.45 (tuntap) |
> | | | |
> +--eth1 192.168.140.254 (mcast) | | (mcast) 192.168.130.254 eth1--+
> | +-----------------------------+ +-----------------------------+ |
> | |
> | +--------------------------+ +--------------------------+ |
> +--eth0 192.168.140.1 (mcast)| |192.168.130.1 (mcast) eth0--+
> +--------------------------+ +--------------------------+
>
> Now i want to reach 192.168.130.1 from 192.168.140.1
> (by ping for example).
>
> Freeswan seems to be configured correctly, ipsec whack --status shows:
> ...
> 000 "vpc45-vpc43":
> 192.168.140.0/24===192.168.150.45...192.168.150.43===192.1
> ...
> (on 192.168.150.43 and 192.168.150.45 too)
>
> If i start to ping 192.168.130.1 from 192.168.140.1, no reply comes
> back.
> If i look with tcpdump on the special interfaces, i see, that the
> icmp-request reaches 192.168.130.1 - but no reply is generated.
>
> Are there any errors in my construction?
> Or can Freeswan/IPSec don't be handled with UML, especially mcast and
> tuntap in this case?
I don't see where you're using bridging in this case, which is the host and
which are UML sessions?
I've never used IPSec but it's just a higher level protocol, there should be
no problem transporting it over tun or a bridge. The higest protocol a
bridge is aware of is ARP at layer 2.
Do you need a VPN between the boxes? It isn't necessary but I can see why
you might want to.
David
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
|
