<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Ok, I was making good progress here right up until I ran into this
snag.<br>
<br>
I have the Blackberry Z-10 authenticating and I can "see" internal
things; I get correct DNS servers for the VPN server back to the
client and I can resolve hostnames provided that I do so on the
gateway machine. <br>
<br>
The environment consists of a local network on em0 with IP
192.168.1.100/24, nominal clients in the range of .1 to .99 on that
subnet. The same machine is both a firewall and NAT gateway to the
outside world with an external interface on em1 at 70.169.168.7.
Default is pointed at the other end of the connection off em1. The
machine runs ipfw for firewall and NAT but cannot run ipfilter (it
is deprecated on FreeBSD and will disappear either in the next
release or the one after that.) A simplified view looks like this:<br>
<br>
PCs/Clients[192.168.1.1-1.99]=====|192.168.1.100 - Gateway/FW/NAT -
70.169.168.7|==== Internet<br>
<br>
(The actual internal network is considerably more complex in that it
includes both wired and wireless client machines, but is bridged and
thus that complexity is transparent to the gateway machine.)<br>
<br>
The goal is to have the VPN "road warrior" connection appear to be
as if it is one of the local PCs when connected; it could be
connecting from anywhere on the Internet and may be behind a NAT
device (will be, most-likely, although that particular aspect of the
problem appears to be handled properly in that it is the visible IP
number that shows up below.) It is perfectly acceptable to have to
stick another address range on the internal network address as an
alias, or I can "carve out" a reasonable number of IPs from the
192.168.1 block (which is what I do with LT2P/PPTP.)<br>
<br>
This is what I have now:<br>
<br>
[root@NewFS /usr/local/etc]# more strongswan.conf<br>
# strongswan.conf - strongSwan configuration file<br>
<br>
charon {<br>
<br>
dns1 = 192.168.1.100<br>
<br>
# number of worker threads in charon<br>
threads = 16<br>
<br>
# send strongswan vendor ID?<br>
# send_vendor_id = yes<br>
<br>
plugins {<br>
<br>
sql {<br>
# loglevel to log into sql database<br>
loglevel = -1<br>
<br>
# URI to the database<br>
# database = sqlite:///path/to/file.db<br>
# database =
mysql://user:password@localhost/database<br>
}<br>
}<br>
<br>
# ...<br>
}<br>
<br>
pluto {<br>
<br>
}<br>
<br>
libstrongswan {<br>
<br>
# set to no, the DH exponent size is optimized<br>
# dh_exponent_ansi_x9_42 = no<br>
}<br>
<br>
And in ipsec.conf:<br>
[root@NewFS /usr/local/etc]# more ipsec.conf<br>
# ipsec.conf - strongSwan IPsec configuration file<br>
<br>
# basic configuration<br>
<br>
config setup<br>
# strictcrlpolicy=yes<br>
# uniqueids = no<br>
<br>
# Add connections here.<br>
<br>
# Sample VPN connections<br>
<br>
<br>
conn %default<br>
keyingtries=1<br>
keyexchange=ikev2<br>
authby=secret<br>
<br>
conn remote<br>
left=70.169.168.7<br>
leftsubnet=192.168.1.0/24<br>
right=%any<br>
rightsourceip=10.0.1.0/24<br>
leftsourceip=192.168.1.100<br>
auto=add<br>
<br>
"left" is my external IP address and leftsubnet is the internal
subnet on the other interface. "em1" has the external address,
"em0" has the internal.<br>
<br>
When I connect I now am able to authenticate and the phone is happy
with the connection and shows that it is linked and stable. Looking
at the gateway I have this in ipsec status:<br>
<br>
[root@NewFS /usr/local/etc]# ipsec status<br>
Security Associations (1 up, 0 connecting):<br>
remote[3]: ESTABLISHED 10 minutes ago,
70.169.168.7[70.169.168.7]...208.54.35.229[<a class="moz-txt-link-abbreviated" href="mailto:karl@denninger.net">karl@denninger.net</a>]<br>
remote{3}: INSTALLED, TUNNEL, ESP in UDP SPIs: ca1ce720_i
058e0c34_o<br>
remote{3}: 192.168.1.0/24 === 10.0.1.1/32 <br>
<br>
The system is running NAT to handle internal clients behind it,
along with an ipfw firewall. I <u><b>do not</b></u> have access to
ipfilter; that's deprecated in FreeBSD and while I might be able to
support it right now I won't be in the future as it has officially
been announced as EOL.<br>
<br>
When I first got the connection stable I could not see anything.
Digging around with tcpdump I discovered that packets were coming in
on the 10.x.x.x network <u><b>but on em1</b></u>, so I had to tell
ipfw that this was permitted (normally I prevent all "internal only"
addresses from passing through that interface.) Once I did this I
could "see" anything that's on the host that is doing the
translation itself.<br>
<br>
I could not, however, get out at all -- including seeing things on
the local network (including the OTHER DNS server that is on the
internal network at .200.) I thought this was due to the 10.x
network being the source (despite the leftsource declaration) and
not going through NAT since the packets are coming in on the wrong
interface but it looks like I'm wrong on that; I looked up an
internal web page on the same server and viewed it and was shocked
to find this appear in the logs while doing so:<br>
<u><b><br>
</b></u><u><b>208.54.35.229</b></u> - - [20/Apr/2013:10:32:43
-0500] "GET / HTTP/1.1" 200 3028 "-" "Mo<br>
zilla/5.0 (BB10; Touch) AppleWebKit/537.10+ (KHTML, like Gecko)
Version/10.0.10.<br>
672 Mobile Safari/537.10+"<br>
<u><b>208.54.35.229</b></u> - - [20/Apr/2013:10:32:44 -0500] "GET
/email.gif HTTP/1.1" 304 - "<br>
<a class="moz-txt-link-freetext" href="http://www.denninger.net/">http://www.denninger.net/</a>" "Mozilla/5.0 (BB10; Touch)
AppleWebKit/537.10+ (KHTML<br>
, like Gecko) Version/10.0.10.672 Mobile Safari/537.10+"<br>
<br>
Huh? 208.54.35.229 is the actual <u><b>external</b></u> address
from the other end of the tunnel; what IPSEC appears to have done is
pass the actual <u><b>visible</b></u> external address into my
gateway machine. Now perhaps this is what I should expect it to do
but it leads to an immediate problem because if that address gets
out in a packet beyond the gateway host the replies will go to the
wrong place -- obviously that won't work.<br>
<br>
What I expected was that the packets would be emitted from either
10.0.1.1 or (logically) 192.168.1.100, since that was declared as
the left (local) source address. Nope.<br>
<br>
Looking on the phone I see no evidence of the external address at
all; only the internal private server address, the internal subnet
and the server's IP.<br>
<br>
So I guess the questions are:<br>
<br>
1. Am I configured wrong on strongswan? That is, shouldn't the
packets coming into the gateway machine, after decryption and
processing, have the internal virtual IP that was assigned to them
as their claimed source? <br>
<br>
2. If not, how do you handle this situation?<br>
<br>
I looked over the configuration examples in the Wiki at <a
href="http://wiki.strongswan.org/projects/strongswan/wiki/IKEv2Examples">http://wiki.strongswan.org/projects/strongswan/wiki/IKEv2Examples</a>
and don't see an obvious way to obtain what I'm looking for here or
an example config that applies to this sort of circumstance. In
short what I want to be able to do is VPN into the local network <u><b>as
if I was a machine on it</b></u>, so from all appearances it is
as if the phone is <u><b>inside</b></u> the local net. I should
thus be able to both access local resources and get out to the
Internet at large through the gateway, using its NAT capability.<br>
<br>
What am I missing?<br>
<br>
(PS: The non-IPSEC/IKEv2 way to do this for Win7 which uses PPTP is
also configured on this host and works as expected, so I may be a
bit "polluted" in my thinking in this regard. Please be a bit
gentle if you can for that reason :-))<br>
<br>
<div class="moz-signature">--<br>
-- Karl Denninger<br>
<a href="http://market-ticker.org"><i>The Market Ticker ®</i></a><br>
Cuda Systems LLC</div>
</body>
</html>