Sorry for the late reply.
Indeed 192.168.8.254 is the IP Address of the internal NIC. In fact I
only have one NIC on my OpenBSD Server (it's a Mac Cube, so I cannot
add another one). It's setup as the default router for the other
systems (through DHCP). Below is the contents of my isakmpd.conf. I
made a mistake in the first mail, my vpnid is 192.168.2.1.
[General]
Default-phase-1=lifetime= 28800,60:86400
Default-phase-2=lifetime= 28800,60:86400
Default-phase-2-suites= QM-ESP-3DES-SHA-SUITE
Default-phase-1-ID= My-ID
Use-Keynote= yes
Logverbose= yes
[X509-certificates]
CA-directory= /etc/isakmpd/ca/
Cert-directory= /etc/isakmpd/certs/
Private-key= /etc/isakmpd/private/my.work.nl.key
Accept-self-signed= yes
[Phase 1]
Default= WORK-Phase1
[Phase 2]
Connections= WORK-Phase2
[WORK-Phase1]
Phase= 1
Transport= udp
Configuration= WORK-Phase1-mode
Address= <REMOTE-ADDRESS>
ID= My-ID
Remote-ID= WORK-ID
[My-ID]
ID-type= FQDN
Name= my.work.nl
[WORK-ID]
ID-type= FQDN
Name= vpn.work.nl
[WORK-Phase2]
Phase= 2
ISAKMP-peer= WORK-Phase1
Configuration= WORK-Phase2-mode
Local-ID= Recursive-Address
Remote-ID= WORK-Network
Flags= Active-only
[Recursive-Address]
ID-Type= IPV4_ADDR
Address= 192.168.2.1
[WORK-Network]
ID-Type= IPV4_ADDR_SUBNET
Network= 192.168.1.0
Netmask= 255.255.255.0
[WORK-Phase1-mode]
DOI= IPSEC
EXCHANGE_TYPE= ID_PROT
Transforms= 3DES-SHA
[WORK-Phase2-mode]
DOI= IPSEC
EXCHANGE_TYPE= QUICK_MODE
Suites= QM-ESP-3DES-SHA-SUITE
[3DES-SHA]
AUTHENTICATION_METHOD= RSA_SIG
And off course, there are also these rules in /etc/pf.conf
pass quick on { lo, enc0, tun0 }
pass quick inet proto esp all keep state
pass quick inet proto udp to any port { 500, 4500 } keep state
pass quick inet proto icmp all icmp-type { $icmp_types } keep state
block return quick on gem0 inet proto tcp to any port { auth }
This is all I have. So traffic comming in from the clients to the
target network 192.168.0.0 will be 'grabbed' by the SA which was
added from hostname.enc0. The traffic will then be natted by the pf
rule and flow towards the remote network.
Hope this helps.
Still I think if you can you should give OpenVPN a try.
Regards,
--
Stephan
On 21-dec-2005, at 22:45, Matthew Closson wrote:
On your question, this is what I have used form my IPSec tunnel's
nat:
Internal network 192.168.8.0/24
Remote network 192.168.1.0/24
vpnip="192.168.1.1"
scrub in
nat on enc0 from { gem0, gem0:network } -> $vpnip
Together with:
# cat /etc/hostname.enc0
up
!ipsecadm flow -out -require -proto esp -src 192.168.8.254 -dst
<REMOTE-ENDPOINT> -addr 192.168.8.0/24 192.168.1.0/24
Is 192.168.8.254 is the IP address of your internal NIC?
Once this has been done, and a fake phase2 entry has been made for
the internal network in the isakmpd.conf file, what else needs to
be done.
I tried this and added the flow and phase2 connection (on my end
only) and when I try to access hosts across the tunnel from my
internal LAN and run tcpdump -i enc0 I still see no traffic coming
across.
Any ideas of what I could be missing? I did
ipsecadm flow -out -require -proto esp -src 192.168.20.250 -dst
a.b.c.d -addr 192.168.20.0/24 192.168.60.0/24
Thanks,
-Matt-
And that worked fine for me. So you'll need to 'manually' add a
Security Association.
Kind regards,
--
Stephan
On 21-dec-2005, at 10:09, Matthew Closson wrote:
Hello,
I'm running into an issue which was brought up on the list
before, the last reference I found was in 2004:
http://archive.openbsd.nu/?ml=openbsd-pf&a=2004-10&m=430206
I have an OpenBSD 3.8 machine.
dc0 is an internal NIC assigned 192.168.20.250
fxp0 is an external NIC assigned a.b.c.d public_IP_address
10.0.20.254 is an inet alias on fxp0
192.168.20.0/24 is my internal network.
192.168.20.0/24
|
|
|
192.168.20.250 - dc0
10.0.20.254 - inet alias on fxp0
a.b.c.d - fxp0 public_IP
|
|
IPSEC Tunnel
|
|
e.f.g.h - public_IP tunnel endpoint
192.168.60.0/24 remote network
According to the parameters of the tunnel setup (of which I
cannot change) the remote IPSEC tunnel endpoint expects traffic
from my network to look like it is coming from 10.0.20.254/32.
This works:
ping -I 10.0.20.254 192.168.20.10
I get responses back from the pings, now I need to nat my
internal network to appear to be coming from 10.0.20.254
So I can do:
nat pass on enc0 from 192.168.20.0/24 to 192.168.60.0/24 ->
10.0.20.254
And what happens is, packets coming in from the 192.168.20.0/24
network hit my internal NIC, are evaluated for IPSEC routing, are
not part of an SPI and are not sent over enc0. This is because
IPSEC routing takes place before pf and nat.
In the message I linked to above, Cedric said that you can get
around this by creating a fake flow into an existing SPI so that
your incoming traffic gets routed into enc0 and then nat'd
appropriately. He said you could run this flow from a cron
script, I suppose that would run every period of time that your
SPI times out.
This doesn't seem real solid to me if you need traffic to stay up
over your tunnel. If your script doesn't run at the right time,
your existing connections over the tunnel are going to fall
apart. In another message someone suggested patching isakmpd to
modify this behavior.
My questions are:
Is there a better or newer way of doing NAT before IPSEC routing?
Does anyone have a script for adding fake flows to SPI's
periodically?
Does anyone have a source patch for isakmpd that solves this issue?
Any info is much appreciated,
I am subscribed to the list.
Thanks,
-Matt-
