[oclug] ipsec + interfaces

[Bart Trojanowski]

James,
  you may want to post your query on the <linux-ipsec at freeswan.org>
mailing list.

Bart.

On Mon, 5 Mar 2001, James Leigh wrote:

> I had been setting up a vpn across the Internet using freeswan.  By default
> the ipsec interface adopts the setting of the interface it travels on
> (ipsec0=eth0).  Further more all tunnels on the parent interface (eth0)
> must travel through the same ipsec interface.
>   This caused some trouble with a remote machine over ipsec, since I wanted
> it to be treated (security wise) as a friendly machine, but its ip was not
> part of any internally trusted networks.  I started looking into changing
> the ip of the ipsec interface.  Reading through the docs on freeswan, I did
> not find much, but a brief topic about Road Warrior with virtual IP
> address.  This described how to allow a remote machine to responded to a
> virtual address, but not use this address to send packets.
>   In my example I did not want to create a virtual address, but have the
> gateway use its internal address(eth1) when talking over the vpn.  Since
> the gateway already accepts packets to the internal address it was just a
> matter of changing the address 'from' in the packet being sent.  I am using
> a 2.2.x kernel so I did not have fancy firewalling to masquerade the
> address; I had to change the ipsec interface directly.
>   After all establishing ipsec tunnels, I running 'ifconfig ipsec0 inet
> 192.168.1.1 broadcast 192.168.1.127 netmask 255.255.255.128'.  This will
> change the ip used on the ipsec0 interface to the one specified.  From that
> time on all traffic going out from ipsec0 will have the return address of
> the new ip (192.168.1.1).
>   Let me now explain the basic setup.  Here is a simple 192.168.1.0/24
> split between two networks.
>
> localnetA         -          getawayA         - internet     -
> gatewayB           -    localnetB
> 192.168.1.0/25    -    192.168.1.1/1.2.3.4    - 0.0.0.0/0    -
> 5.6.7.8/192.168.1.129    -    192.168.1.128/25
>
> ipsec.conf for gatewayA: (same/similar for B)
> config setup
>     ...
> conn %default
>     ...
> conn netB
>     also=gatewayB
>     also=leftnet
>     auto=start
> conn gatewayB
>     # identify the remote machine
>     rightid=@gatewayB
>     right=5.6.7.8
>     rightsubnet=192.168.1.128/25
>     rightrsasigkey=0x3fdd8....
> conn leftnet
>     leftsubnet=192.168.1.0/25
>     also=lefthost
> conn lefthost
>     # identify the local machine
>     leftid=@gatewayA
>     left=%defaultroute    # 1.2.3.4
>     leftrsasigkey=0x3fdd8....
>
> When the two gateways A and B connect via ipsec it connects with their eth0
> (external) address, then each independently changes its ipsec0 interface to
> use it internal address, from that point on gatewayA and B communicate
> using their local(eth1) addresses.  Some things to note about the
> ipsec.conf file is that both gateways and both internal networks use the
> same ipsec tunnel (netB).  It is also significant to note that gatewayA can
> communicate with B via 192.168.1.129 or 5.6.7.8 in the vpn and outside the
> vpn respectively, similar for B->A.  This means that each machine can
> choose to communicate inside the vpn or outside.
>   In summary here are the pros and cons
> pros:
>     1. use internal ip on vpn
>     2. one tunnel for gateway and subnets
>     3. machines can shutdown and reconnect without disturbing other party
>     4. two ips for every gateway in or out (good for debugging)
> cons:
>     1. cannot bring up a connect with incorrect interface info; have to
> correct ipsec0 before adding any tunnels
>     2. still have to use the same ip for all ipsec0 tunnels
>     3. route table has to be rebuild for ipsec0 every time ipsec0 changes;
> ifconfig removes all ipsec0 entries then add a general entry
>     4. two ips for every gateway in or out (may expect to be in, but really
> out), can be corrected by adding a second tunnel
>
>   After talking with Richard at the last meeting, I thought it would be
> good to post my solution and get some feed back.  Maybe we
> could include it in the documentation.
>
> cheers mates,
> james
>
> _______________________________________________
> oclug mailing list
> oclug at lists.oclug.on.ca
> http://www.oclug.on.ca/mailman/listinfo/oclug
>

-- 
	WebSig: http://www.jukie.net/~bart/sig/