IPSec client for B3

[stasheck]

Turns out that if you buy a few B3 for friends, you'll get a lot of weird requests...

So I have a B3 and I need to connect to it to an Netscreen/Juniper SSG140. Does anyone has any experience with setting up an IPSec VPN between Linux and a Netscreen?

I searched through the forum and wiki here (and on Google), found a few things but most are old enough that I am not certain if they still apply - for example this wiki entry: http://wiki.mybubba.org/wiki/index.php? ... rt_on_a_b3. Especially since 2nd step is "install strongswan", and I'm pretty sure there's no StrongSWAN package in repos now.

I tried vpnc, after some fiddling with Netscreen it claimed that it established the connection, but Netscreen simultaineausly said "VPN is up" and "Tunnel interface is down", refusing to pass any traffic. There's not much info regarding ScreenOS config for Linux IPsec VPN solutions, and what there is is either old or very fragmented.

Since I'm not sure if I'm making mistakes on B3 side or on Netscreen side, I'd like to have at least one of them right. Can anyone share his _working_ IPSec setup for B3?

[Gordon]

Hi

I actually never managed to get strongswan running. That is: I could connect and list files from a share on the other side, but everything else would crash my B3 (more details here).

Strongswan is in the official repo BTW. You just need to add that to your sources list, because in the original setup you only get to see what Excito chose to mirror. Check debian.org for a local mirror you can use. The alternative openswan seems to have disappeared from the repo, so you would have to compile this yourself. If you run into the same issues I did when attempting to use strongswan, you will need those sources anyway to build the klips module. You will also need to recompile bubba-kernel, because in the latest version to chose to add xfrm and netkey (which are the cause for the B3 crashing) to the kernel itself rather than ship these as modules, and they will prevent the klips module from loading.

Openswan config for reference:

Code: Select all

version	2.0	

config setup
  nat_traversal=no
  #virtual_private = anything that is on the other side and not on your side
  # here: all RFC 1918 ranges and excluding my own LAN range (! means not)
  virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
  oe=off
  protostack=klips   # openswan only - use netkey with strongswan

conn %default
  keyingtries=1
  compress=yes
  disablearrivalcheck=no
  authby=rsasig
  leftrsasigkey=%cert
  rightrsasigkey=%cert
  ike=3des-sha1,3des-md5
  esp=3des-sha1,3des-md5

conn my_peer
  type=tunnel
  authby=rsasig
  auth=esp
  keyexchange=ike
  compress=no
  rekey=yes
  pfs=no
  left=10.10.10.10   # change to match the public IP of your peer - don't use DNS name!
  leftid=@gatekeeper.my_peer.com
  leftrsasigkey=<left secret key>
  right=%defaultroute
  rightsubnet=192.168.1.0/24
  rightid=@www.bosvangennip.nl
  rightrsasigkey=<right secret key>

conn my_peer-subnet1
  leftsubnet=192.168.10.0/24
  also=my_peer
  auto=add

conn my_peer-subnet2
  leftsubnet=10.0.0.0/24
  also=my_peer
  auto=add


conn packetdefault
  auto=ignore

conn block
  auto=ignore

conn clear
  auto=ignore

conn private
  auto=ignore

conn clear-or-private
  auto=ignore

conn private-or-clear
  auto=ignore

In this case 'left' is my peer and 'right' is me. You can reverse this, but it has to match with what the peer says is 'left' and 'right'. I'm also using RSA 2192 bits secret keys in this case. If you're trying to connect to juniper ipsec you will likely need to use shared key authorization (authby=secret).

[stasheck]

So, back on track.

I followed the guide here: https://sites.google.com/site/bingsite/ ... reenos-6-2

It *seems* to work, "seems" being the keyword. Problem is, tunnel gets up (confirmed with tcpdump, logs on racoon and logs on SSG): I have phase1&2 messages, but then, nothing.

Tunnel gets up when I trigger it by sending ping from behind B3, but then nothing is being transmitted. After the tunnel is up I also tried to ping from the other side, to no effect (again, no packets).

The thing that comes to my mind, when I read about this stuff before, there always seemed to be some kind of tunnel interface visible in 'ip a s' output - now there isn't. Can this be the case? What am I missing?

[Gordon]

When using ipsec with netkey there is no additional interface. It simply uses your WAN interface. Not an improvement IMO, as it complicates debugging and monitoring. First thing to check is your firewall - did you add a blocking rule for RFC1918 addresses on eth0?