Dear list:
Erich Titl has already given me great help (off-list -- much thanks to
him) on this, but I thought I would post to the leaf list and verify
some conclusions.
They are:
1) The Nat-traversal patch available in Bering ipsec does UDP
encapsulation after any masquerading. The particular situation is a
win2k machine with a roadwarrior IP security policy as described in the
Bering users guide, as well as the Freeswan site.
2) It will be necessary to perform nat-traversal on the win2k box
itself.
If anyone can verify the above two points are true, I would be grateful.
Each fw masquerades outbound.
See log file records from office fw at the end.
I have the following configuration
Offce win2k
137.45.192.86 eth sw- 137.45.192.69(office FW) -
192.168.10.0/24
ping works fine |
(Campus Net)
|
(Internet)
|
HomeFW 192.168.1.0/24
|
win2k box,
IP security Policy as
described in the bering users guide
Can't ping from (192.168.1.3) to 192.168.10.x behind office fw.
I am using two Bering 1.2 firewalls with SuperFreeSwan and the
nat-traversal patch is enabled (on both -- most importantly the home
FW).
Each Win2k box is set up quite identically, following some road-warrior
configs from the freeswan examples.
The differences are:
1)The home win2k box goes the HomeFW.
2)The outbound/inbound IP security filters of course name a different
src/dest endpoint.
The symptoms are as follows: I can ping, telnet etc from a machine just
outside the office firewall, but not from a virtually identical setup
behind the home FW. The auth.log on the office firewall gives a few
interesting records: From the home fw (216.12.22.89) we see in the
office FW auth.log a record: Jul 28 18:45:25 firewall pluto[21755]:
"road-warrior"[2] 216.12.22.89#1: sent MR3, ISAKMP SA established
So the Key mgmt SA is accepted.
But from there things go downhill. Why would this log message be issued
on the office FW one second later? Jul 28 18:45:26 firewall
pluto[21755]: "road-warrior"[2] 216.12.22.89 #1: cannot respond to
IPsec SA request because no connection is known for 192.168.10.0/24=
==137.45.192.69...216.12.22.89[192.168.1.3]===192.168.1.3/32
I think the above record from auth.log is where things go wrong, but
why?
Is it the apparently strange IP addresses, as the tail of auth.log
complains: firewall pluto[21755]: "road-warrior"[2] 216.12.22.89 #721:
Main mode peer ID is ID_IPV4_ADDR: '216.12.22.89' Jul 29 09:46:59
firewall pluto[21755]: "road-warrior"[2] 216.12.22.89 #721: we r equire
peer to have ID '192.168.1.3', but peer declares '216.12.22.89'
Why doesn't nat traversal on Bering take care of this? Is there
something wrong with my config?
TIA for any help Rick.
My Office IPSec.conf is:
# /etc/ipsec.conf - FreeS/WAN IPsec configuration file
# More elaborate and more varied sample configurations can be found # in
FreeS/WAN's doc/examples file, and in the HTML documentation.
# basic configuration
config setup
# THIS SETTING MUST BE CORRECT or almost nothing will work;
# %defaultroute is okay for most simple cases.
interfaces=%defaultroute
#interfaces="ipsec0=eth0"
# Debug-logging controls: "none" for (almost) none, "all" for
lots.
klipsdebug=none
plutodebug=none
# Use auto= parameters in conn descriptions to control startup
actions.
plutoload=%search
plutostart=%search
# Close down old connection when new one using same ID shows up.
uniqueids=yes
nat_traversal=yes
# defaults for subsequent connection descriptions
conn %default
# How persistent to be in (re)keying negotiations (0 means
very).
keyingtries=0
# RSA authentication with keys from DNS.
#authby=rsasig
# Authentication by pre-shared secret key
authby=secret
#left=137.45.192.69
left=%defaultroute
leftsubnet=192.168.10.0/24
#leftnexthop=%direct
leftfirewall=yes
pfs=yes
auto=add
#leftrsasigkey=%dns
#rightrsasigkey=%dns
conn road-warrior
right=%any
# connection description for (experimental!) opportunistic encryption #
(requires KEY record in your DNS reverse map; see doc/opportunism.howto)
#conn me-to-anyone
# left=%defaultroute
# right=%opportunistic
# uncomment to enable incoming; change to auto=route for
outgoing
#auto=add
# sample VPN connection
conn sample
# Left security gateway, subnet behind it, next hop toward
right.
left=10.0.0.1
leftsubnet=172.16.0.0/24
leftnexthop=10.22.33.44
# Right security gateway, subnet behind it, next hop toward
left.
right=10.12.12.1
rightsubnet=192.168.0.0/24
rightnexthop=10.101.102.103
# To authorize this connectio
