(Real information to follow summary)
$ uname -a
OpenBSD hivpn3<snip> 4.0 GENERIC.MP#967 amd64
Gateway: 2 IPsec gateways running OpenBSD 4.0 using carp on the public
interface (fail-over w/ preempt), sasyncd, and pfsync.
Clients: "Road-warrior" type clients (Mac OS X using the "VPN Tracker"
software bu equinux) who need access to an internal class C network. The
clients are configured to authenticate using x509 certs and use "mode
config" for ip addr assignment.
On the one hand, everything works amazingly well. Phases 1 and 2
complete successfully and the clients are assigned the proper IP
address. From the gateway I can ping the remote client and ssh into it.
The client can do the same for the gateway.
I am experiencing an issue that none of the clients can talk to any
other machines on the private network. tcpdump-ing the gateway's enc0
shows all the packets arriving from the mode-config assigned addresses.
No response packets are returned over the tunnel. tcpdump-ing the bge1
(interface to the internal net) shows the packets leaving on their way
to the right host. It appears that no arp requests are being answered by
the remote client (or perhaps by proxy the gateway?, see output below).
Disabling mode-config gives the same results.
How is this supposed to work? It seems like all documentation on this
subject ignores packet routing nuances entirely.
Perhaps if I assign remote clients addresses in a different address
space and force the target network to use the gw box as the known route
to that network? I haven't seen this scenario in any of the
documentation (or google hits). Most users seem to experience that "this
just works".
I reduced the test scenario to ease troubleshooting to a single gateway
(no carp, sasyncd or pfsync) and I am experiencing the same problem.
Things that I know:
-Packet forwarding is enabled (net.inet.ip.forwarding=1)
-Gateway's routes (.21 is gateway, .100 is a server on the internal,
bge1 is the correct default route for the 192.168.3/24:
192.168.3/24 link#2 UC 2 0 - bge1
192.168.3.21 link#2 UHLc 1 1257 - bge1
192.168.3.100 00:a0:d1:e4:f7:85 UHLc 0 824 - bge1
-tcpdump enc0 (on gateway during an attempt to ping server .10 from a
remote client):
10:40:24.792241 (authentic,confidential): SPI 0xaab2bb0f: 192.168.3.201
> 192.168.3.100: icmp: echo request (encap)
-tcpdump bge1 (interface associated with internal .3/24 net on gw):
10:42:42.820051 192.168.3.201 > 192.168.3.100: icmp: echo request
10:42:42.825013 arp who-has 192.168.3.201 tell 192.168.3.100
(no arp response from client or gw)
-netstat -rnf encap
Routing tables
Encap:
Source Port Destination Port Proto
SA(Address/Proto/Type/Direction)
192.168.3.201/32 0 192.168.3/24 0 0
150.135.23.12/esp/use/in
192.168.3/24 0 192.168.3.201/32 0 0
150.135.23.12/esp/require/out
-ipsecctl -s all
flow esp in from 192.168.3.201 to 192.168.3.0/24 peer 150.135.23.12
srcid <ext. if ip>/32 dstid [EMAIL PROTECTED] type use
flow esp out from 192.168.3.0/24 to 192.168.3.201 peer 150.135.23.12
srcid <ext. if ip>/32 dstid [EMAIL PROTECTED] type require
-isakmpd.conf (shouldn't matter since remote hosts seem to make it
through keying, but for reference):
# cat /etc/isakmpd/isakmpd.conf
[General]
Listen-on= <snip, was ip addr of external interface>
Policy-file= /etc/isakmpd/isakmpd.policy
[X509-Certificates]
Ca-directory= /etc/isakmpd/ca/
Cert-directory= /etc/isakmpd/certs/
Private-key= /etc/isakmpd/priv-key.pem
[Phase 1]
Default= Default-peer
[Phase 2]
Passive-connections= Default-connection
[Default-peer]
Phase= 1
[Default-connection]
Configuration= Default-ipsec-config
ISAKMP-peer= Default-peer
Phase= 2
Local-ID= Local-net
Remote-ID= Default-remote-ID
[Default-ipsec-config]
EXCHANGE_TYPE= QUICK_MODE
Suites= QM-ESP-AES-SHA-PFS-SUITE
[Local-net]
ID-type= IPV4_ADDR_SUBNET
Network= 192.168.3.0
Netmask= 255.255.255.0
[Default-remote-ID]
ID-type= IPV4_ADDR
Address= 0.0.0.0
# Client Mode-Config Section
[ufqdn/[EMAIL PROTECTED]
Address= 192.168.3.201
Netmask= 255.255.255.0
--
Shawn Nock
Systems Programmer, Senior
CCIT; University of Arizona
nock 'at' arizona 'dot' edu
