[vpn-help] Linux Road Warrior: Shrew 2.1.5 -> OpenBSD 4.7

[Matthew Grooms]

On 4/7/2010 8:01 AM, Toni Mueller wrote:
>
> Hello,
>
> I'm trying to connect with Shrew 2.1.5 under Debian Testing road
> warrior (kernel 2.6.32) to an OpenBSD machine that runs a current
> snapshot of OpenBSD (ie, almost 4.7). My desired setup is as follows:
>
>             Debian box ---- Internet ---- OpenBSD box (gateway)
>
> 192.168.3.1/32 (1.2.3.4) ---- Internet ---- (3.4.5.6) 192.168.1.0/24
>
>   - OR -
>
> 192.168.3.1/32 (1.2.3.4) ---- Internet ---- (3.4.5.6) 0.0.0.0/0
>
> (ie, an assigned private IP address and a default route through the tunnel)
>
>
>
> I've configured the OpenBSD box support IPSEC connections with the
> following properties:
>
> Authentication: X.509 certificates (= RSASIG)
>
> I issue the certificates from my own CA.
>
>
> Phase 1: Debian machine = initiator, OpenBSD machine = responder
>
> main mode, AES 256, SHA1, GRP5
>
> Phase 2: Same thing, plus PFS, plus IKE_CONFIG
>
>
> With this setup, which works flawlessly with at least older NCP clients
> under Windows XP, I have a number of problems:
>
> 1. The moment the server sends an IKE_CONFIG packet, the client logs
>     "config message type is invalid for pull config", and terminates the
>     connection.
>

There are two types of IKE_CONFIG. Push and Pull. If the server is 
trying to send the config to the client before it requests it, thats a 
push. Did you try setting the mode to push? There was also a bug in the 
2.1.5 code that prevented the push method from working with some push 
type gateways. You may need to try the 2.1.6 beta.

> 2. If I set "Autoconfiguration" to "disabled" in the "General" tab, and
>     manually set up a default route in the policies tab, or check
>     "obtain topology automatically", the connection goes down after a
>     few moments due to "gateway is not responding".
>

There should be a policy installed when the connection establishes to 
prevent a 'tunnel all' policy from capturing IKE traffic. Maybe this 
didn't happen for some reason. You would be able to see it using the 
setkey -DP command.

> 3. If I set up only a network route, the connection is claimed to be
>     established from within the client (ikea), but can't be seen on the
>     gateway.
>

The client reports a connection is established once the ISAKMP SA is 
negotiated. You probably didn't see any IPsec SA's negotiated.

> 4. Worst of all, if I ping something in the remote LAN, packets want
>     to go out of ppp0 with a source and/or destination address in
>     RFC1918 range. I'm catching these with iptables, but the packets
>     must only have source and destination addresses in the public IP
>     space, as I'm using ESP and not AH w/o ESP.
>

Its really hard to guess as to whats going on without any log output. 
This would suggest that you don't have any IPsec policies installed to 
require the traffic to be protected by IPsec before being forwarded.

> 5. At no point have I been able to "see" the LAN I want to connect to.
>

I don't know what this means. You have to have the client negotiating 
with the gateway properly before you can talk to the distant network.

>
> I've also compiled, and tried, the most recent 2.1.6-*, but things
> didn't improve.
>
> It would generally be nice if I could resize the settings window so I
> can read everything that is written in there.

The 2.2.x branch is based on qt4 and allows the configuration windows to 
be resized.

-Matthew