From: John A. Sullivan III (John.Sullivan_at_nexusmgmt.com)
Date: Wed Oct 02 2002 - 20:25:21 CEST
Here is some additional information on the below problem.
I tried setting rightnexthop=192.168.110.7 (the private IP address).
That didn't work.
I reconfigured Sentinel to use the public IP address as the tunnel
endpoint. That solved this problem, that is, renegotiations from FSW1
worked perfectly but it completely broke connectivity. Let me discuss
each of those statements a little further.
I changed the Sentinel VPN definition to use the public interface of
FSW1 even though it lives directly connected to the private interface.
As mentioned, the rekeying worked fine. However, the changes to
ipsec.conf were interesting. If I changed the left= parameter for this
connection to the public IP, it complained when Sentinel initiated a
connection that no connection had been authorized. This is despite the
fact that the packet is destined for what is defined as left=. Of
course, the packet itself is showing up on the private interface.
Changing ipsec.conf back to just as it is below, i.e., left={internal
interface IP address} works. I tried changing leftnexthop to the public
IP address and that failed to route (as suspected).
Now, with this new Sentinel configuration, the rekeying works fine but
IPSec is completely broken. I would expect that the ESP packets would
show up in IntIF (i.e., the internal interface - in my case eth0) and
the decrypted packets would then show up on ipsecIntIF (in my case
ipsec0) and then be forwarded out on ipsecPubIF (in my case, ipsec1).
I see the ESP packets on IntIF both through tcpdump on -i IntIF and by
logging the packets in iptables (i.e., I see them on the INPUT chain in
front of the rule that ACCEPTs ESP packets and do not see them on the
INPUT chain after that rule). However, from there they disappear into
thin air (or silicon). tcpdump on ipsec0 and ipsec1 show nothing. If I
log every packet the enters the FORWARD or OUTPUT chains, I see
nothing. I disabled iptables just in case - still nothing.
So I suppose I am stuck. If I could get Free S/WAN to rekey on the
interface that left= is set to, I'd be fine. Failing that, if I could
get IPSec to work when I point an internal Sentinel client to the
external Free S/WAN interface, I'd be fine. As it is, I can't do
either. HELP!!! Thanks - John
On Wed, 2002-10-02 at 12:26, John Sullivan wrote:
> Hello, all. I'm hitting a somewhat strange problem. For security
> reasons, we only allow traffic out of our GNOC's if the user can be
> identified via X.509 cert and is encrypting their traffic. Thus I was
> testing a Sentinel client tunneling to a Free S/WAN gateway which in
> turn forwarded the traffic to another Free S/WAN gateway (the remote
> site). All works splendidly until the local Free S/WAN gateway (we'll
> call it FSW1) tries to rekey.
>
> When FSW1 tries to rekey with the internal client, it sends an
> ISAKMP packet as it should but the source address is the external
> address of FSW1 instead of the internal address. Sentinel seems to
> choke on this. I'm working on the Sentinel part to see if I can find
> a workaround but why does FSW1 insist on inserting the public IP
> address as the source address when rekeying on the private network?
> Here is a boxless diagram and the pertinent section of my ipsec.conf:
>
> Remote LAN
> |
> |
> FSW2 (Remote Free S/WAN gateway)
> |
> |
> Internet
> |
> |
> FSW1
> |
> |
> Sentinel Client
>
> There is a connection defined from the local LAN where the Sentinel
> client resides and the remote LAN. That all works fine. When the
> Sentinel client initiates the renegotiation, it works fine. But when
> FSW1 renegotiates with the Sentinel client it fails. The only
> variation I see is that when the client rekeys, the reply from FSW1
> comes from the internal IP address. When FSW1 rekeys, the packet
> comes from the FSW1 public IP address.
>
> conn LocalGNOC
> left=192.168.110.7 #private IP of FSW1
> leftnexthop=%direct #left next hop is explicitly defined in default
> right=%any # we don't know what addresses are connecting - just
> their subnet
> leftsubnet=0.0.0.0/0.0.0.0 # They could be going anywhere
> rightsubnetwithin=192.168.110.0/24 # This is where they all should
> come from
> auto=add
> leftupdown=/etc/ipsec.d/X509updown # critical script that must run
> with every new connection
>
> How do I get FSW1 to rekey using its private interface? I tried
> setting leftnexthop to 192.168.110.7 (the internal IP of FSW1) but
> Free S/WAN objected violently! Thanks - John
-- John A. Sullivan III Group Technology Director Nexus Management +1 207-985-7880 John.Sullivan_at_nexusmgmt.com _______________________________________________ Users mailing list Users_at_lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.5 : Thu Oct 03 2002 - 05:20:21 CEST