adapted from freeswan-2.05/doc/adv_config.html
Full opportunism allows you to initiate and receive opportunistic connections on your machine. The remaining instructions in this section assume you have first set up full opportunism on your gateway using these instructions?. Both sets of instructions require mailing DNS records to your ISP. You may wish to collect DNS records for both the gateway and the subnet nodes before contacting your ISP.
You need these so that your Opportunistic peers can:
On the gateway, generate a TXT record with:
{{{
ipsec showhostkey --txt 192.0.2.11
}}}
Use your gateway address in place of 192.0.2.11.
You should see (keys are trimmed for clarity throughout our example):
{{{
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
}}}
This MUST BE the same key as in your gateway's TXT record, or nothing will work.
In a text file, make one copy of this TXT record for each subnet node:
{{{
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
}}}
Above each entry, insert a line like this:
{{{
98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.
}}}
It must include:
The result will be a file of TXT records, like this:
{{{
98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
99.2.0.192.in-addr.arpa. IN PTR ford.example.com.
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
100.2.0.192.in-addr.arpa. IN PTR trillian.example.com.
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"
}}}
Ask your ISP to publish all the reverse DNS records you have collected. There may be a delay of up to 48 hours as the records propagate.
Check a couple of records with commands like this one:
{{{
ipsec verify --host ford.example.com
ipsec verify --host trillian.example.com
}}}
The verify command checks for TXT records for both the subnet host and its gateway. You should see output like:
{{{
...
Looking for TXT in reverse map: 99.2.0.192.in-addr.arpa [OK]
...
Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa [OK]
...
Looking for TXT in reverse map: 100.2.0.192.in-addr.arpa [OK]
...
Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa [OK]
...
}}}
Openswan 2.x ships with a built-in, automatically enabled OE connection conn packetdefault which applies OE, if possible, to all outbound traffic routed through the Openswan box. The ipsec.conf(5) manual? describes this connection in detail. While the effect is much the same as private-or-clear, the implementation is different: notably, it does not use policy groups.
You can create more complex OE configurations for traffic forwarded through a Openswan box, as explained in our policy groups document?, or disable OE using these instructions?.
What we call extruded subnets? are a special case of VPNs?.
If your buddy has some unused IP addresses, in his subnet far off at the other side of the Internet, he can loan them to you... provided that the connection between you and him is fast enough to carry all the traffic between your machines and the rest of the Internet. In effect, he "extrudes" a part of his address space over the network to you, with your Internet traffic appearing to originate from behind his Internet gateway.
As far as the Internet is concerned, your new extruded net is behind your buddy's gateway. You route all your packets for the Internet at large out his gateway, and receive return packets the same way. You route your local packets locally.
Suppose your friend has a.b.c.0/24 and wants to give you a.b.c.240/28. The initial situation is:
{{{
subnet gateway Internet a.b.c.0/24 a.b.c.1 p.q.r.s
}}}
where anything from the Internet destined for any machine in a.b.c.0/24 is routed via p.q.r.s and that gateway knows what to do from there.
Of course it is quite normal for various smaller subnets to exist behind your friend's gateway. For example, your friend's company might have a.b.c.16/28=development, a.b.c.32/28=marketing and so on. The Internet neither knows not cares about this; it just delivers packets to the p.q.r.s and lets the gateway do whatever needs to be done from there.
What we want to do is take a subnet, perhaps a.b.c.240/28, out of your friend's physical location while still having your friend's gateway route to it. As far as the Internet is concerned, you remain behind that gateway.
{{{
subnet gateway Internet your gate extruded
a.b.c.0/24 a.b.c.1 p.q.r.s d.e.f.g a.b.c.240/28
========== tunnel ==========
}}}
The extruded addresses have to be a complete subnet.
In our example, the friend's security gateway is also his Internet gateway, but this is not necessary. As long as all traffic from the Internet to his addresses passes through the Internet gate, the security gate could be a machine behind that. The IG would need to route all traffic for the extruded subnet to the SG, and the SG could handle the rest.
First, configure your subnet using the extruded addresses. Your security gateway's interface to your subnet needs to have an extruded address (possibly using a Linux virtual interface?, if it also has to have a different address). Your gateway needs to have a route to the extruded subnet, pointing to that interface. The other machines at your site need to have addresses in that subnet, and default routes pointing to your gateway.
If any of your friend's machines need to talk to the extruded subnet, they need to have a route for the extruded subnet, pointing at his gateway.
Then set up an IPsec subnet-to-subnet tunnel between your gateway and his, with your subnet specified as the extruded subnet, and his subnet specified as "0.0.0.0/0".
The tunnel description should be:
{{{ conn extruded
left=p.q.r.s
leftsubnet=0.0.0.0/0
right=d.e.f.g
rightsubnet=a.b.c.0/28
}}}
If either side was doing firewalling for the extruded subnet before the IPsec connection is set up, you'll need to poke holes in your firewall? to allow packets through.
And it all just works. Your SG routes traffic for 0.0.0.0/0 -- that is, the whole Internet -- through the tunnel to his SG, which then sends it onward as if it came from his subnet. When traffic for the extruded subnet arrives at his SG, it gets sent through the tunnel to your SG, which passes it to the right machine.
Remember that when ipsec_manual or ipsec_auto takes a connection down, it does not undo the route it made for that connection. This lets you take a connection down and bring up a new one, or a modified version of the old one, without having to rebuild the route it uses and without any risk of packets which should use IPsec accidentally going out in the clear. Because the route always points into KLIPS, the packets will always go there. Because KLIPS temporarily has no idea what to do with them (no eroute for them), they will be discarded.
If you do want to take the route down, this is what the "unroute" operation in manual and auto is for. Just do an unroute after doing the down.
Note that the route for a connection may have replaced an existing non-IPsec route. Nothing in Linux Openswan will put that pre-IPsec route back. If you need it back, you have to create it with the route command.
Please note that Super Openswan now features DHCP-over-IPsec, which is an alternate procedure for Virtual IP address assignment.
Here is a mailing list message about another way to configure for road warrior support:
{{{ Subject: Re: linux-ipsec: understanding the vpn
Date: Thu, 28 Oct 1999 10:43:22 -0400 From: Irving Reid <irving@nevex.com>
> local-------linux------internet------mobile > LAN box user > ...
> now when the mobile user connects to the linux box > it is given a virtual IP address, i have configured it to > be in the 10.x.x.x range. mobile user and linux box > have a tunnel between them with these IP addresses.
> Uptil this all is fine.
If it is possible to configure your mobile client software not to use a virtual IP address, that will make your life easier. It is easier to configure Openswan to use the actual address the mobile user gets from its ISP.
Unfortunately, some Windows clients don't let you choose.
> what i would like to know is that how does the mobile > user communicate with other computers on the local > LAN , of course with the vpn ?
> what IP address should the local LAN > computers have ? I guess their default gateway > should be the linux box ? and does the linux box need > to be a 2 NIC card box or one is fine.
As someone else stated, yes, the Linux box would usually be the default IP gateway for the local lan.
However...
If you mobile user has software that must use a virtual IP address, the whole picture changes. Nobody has put much effort into getting Openswan to play well in this environment, but here's a sketch of one approach:
Local Lan 1.0.0.0/24
|
+- Linux Openswan 1.0.0.2
|
| 1.0.0.1
Router
| 2.0.0.1
|
Internet
|
| 3.0.0.1
Mobile User
Virtual Address: 1.0.0.3
Note that the Local Lan network (1.0.0.x) can be registered, routable addresses.
Now, the Mobile User sets up an IPSec security association with the Linux box (1.0.0.2); it should ESP encapsulate all traffic to the network 1.0.0.x **EXCEPT** UDP port 500. 500/udp is required for the key negotiation, which needs to work outside of the IPSec tunnel.
On the Linux side, there's a bunch of stuff you need to do by hand (for now). Openswan should correctly handle setting up the IPSec SA and routes, but I haven't tested it so this may not work...
The Openswan conn should look like:
conn mobile
right=1.0.0.2
rightsubnet=1.0.0.0/24
rightnexthop=1.0.0.1
left=0.0.0.0 # The infamous "road warrior"
leftsubnet=1.0.0.3/32
Note that the left subnet contains only the remote host's virtual address.
Hopefully the routing table on the Openswan box ends up looking like this:
% netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 1.0.0.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 lo 0.0.0.0 1.0.0.1 0.0.0.0 UG 1500 0 0 eth0 1.0.0.3 1.0.0.1 255.255.255.255 UG 1433 0 0 ipsec0
So, if anybody sends a packet for 1.0.0.3 to the Linux box, it should get bundled up and sent through the tunnel. To get the packets for 1.0.0.3 to the Linux box in the first place, you need to use "proxy ARP".
How this works is: when a host or router on the local Ethernet segment wants to send a packet to 1.0.0.3, it sends out an Ethernet level broadcast "ARP request". If 1.0.0.3 was on the local LAN, it would reply, saying "send IP packets for 1.0.0.3 to my Ethernet address".
Instead, you need to set up the Linux box so that _it_ answers ARP requests for 1.0.0.3, even though that isn't its IP address. That convinces everyone else on the lan to send 1.0.0.3 packets to the Linux box, where the usual Openswan processing and routing take over.
% arp -i eth0 -s 1.0.0.3 -D eth0 pub
This says, if you see an ARP request on interface eth0 asking for 1.0.0.3, respond with the Ethernet address of interface eth0.
Now, as I said at the very beginning, if it is at all possible to configure your client not to use the virtual IP address, you can avoid this whole mess. }}}
Sometimes you have to cope with a situation where the network interface(s) aren't all there at boot. The common example is notebooks with PCMCIA.
The key issue here is that the config setup section of the /etc/ipsec.conf configuration file lists the connection between ipsecN and hardware interfaces, in the interfaces= variable. At any time when ipsec setup start or ipsec setup restart is run this variable must correspond to the current real situation. More precisely, it must not mention any hardware interfaces which don't currently exist. The difficulty is that an ipsec setup start command is normally run at boot time so interfaces that are not up then are mis-handled.
Normally, an ipsec setup start is run at boot time. However, if the hardware situation at boot time is uncertain, one of two things must be done.
{{{
chkconfig --level 2345 ipsec off
}}}
{{{
interfaces=
}}}
When the hardware is in place, IPsec has to be made aware of it. Someday there may be a nice way to do this.
Right now, the way to do it is to fix the /etc/ipsec.conf file appropriately, so interfaces reflects the new situation, and then restart the IPsec subsystem. This does break any existing IPsec connections.
If IPsec wasn't brought up at boot time, do
{{{
ipsec setup start
}}}
while if it was, do
{{{
ipsec setup restart
}}}
which won't be as quick.
If some of the hardware is to be taken out, before doing that, amend the configuration file so interfaces no longer includes it, and do
{{{
ipsec setup restart
}}}
Again, this breaks any existing connections.
