Brandon,
FYI... Actually it was the 100000KB rule. The time does not matter. I
can use 1800s, I can also use 24h. I know it for fact because the
problem was fixed as soon as he turned off the KB/rekey rule on the
AS/400 end.
Joshua Myner : MCP, MMCP
Systems Administrator / Application Developer
jmyner_at_gsite.com : (616)324-8231 Ext. 17
Granite Solutions http://www.gsite.com
-----Original Message-----
From: Brandon Peterson [mailto:bsp_at_mcintoshsoftware.com]
Sent: Monday, May 20, 2002 11:56 AM
To: Myner, Josh; hugh_at_mimosa.com
Cc: Richard Welty; FreeS/WAN Users
Subject: RE: Re[4]: [Users] Freeswan Proposal Syntax
Josh,
Ok, here is the deal.
Notice how the AS/400 reports the local policy as 1800 sec? When the
AS/400 is proposing to the FreeS/WAN
machine, FreeS/WAN is saying ok, the 1800 seconds requested by the
AS/400 is less than my time out. So, that is
acceptable.
However, when the FreeS/WAN machine proposes to the AS/400, the AS/400
says the proposed 28800 secs is way
out of it's range of acceptable values.
So, in your configuration in FreeS/WAN specify a keylife=1800s.
Alternatively, get the AS/400 lifetime set to 28800 or
so.
Brandon
5/18/02 11:56:27 PM, "Myner, Josh" <jmyner_at_gsite.com> wrote:
>
>Regretfully, the guy on the AS/400 end can't upgrade due to management
>decisions. (Or so I'm told). On a positive
note, it appears the ISAKMP SA is being established successfully now.
The weird thing is... I haven't changed anything
since the MR1 would not work. My guess is he did a reboot. Anyway, the
IPsec connection is not coming up. I'm
thinking this is either the AS/400 denying the connection based on
policy, a routing problem with the ipsec0 interface on
my end, or some other unknown bug. None of it seems to add up correctly
though. I got word back that I'm filling up his
error log.. ha.. (and he said there was no error.. sheesh).
>
>Here is the error from his AS/400 end..
>
>----------------------------------------------------------
>Message ID . . . . . . : TCP870C
>Date sent . . . . . . : 05/18/02 Time sent . . . . . . :
19:26:09
>Message . . . . : Proposal not accepted with remote system
12.27.12.116
>Cause . . . . . : A proposal was not chosen when negotiating with
remote
> system 12.27.12.116 for VPN connection RESPONDER. The following
>additional
> information may be useful in resolving the problem:
> Proposed Exchange: 32.
> Local Role: Responder.
> Remote Proposal:
ESP,3DES,XPORT,28800SEC,MD5:ESP,3DES,XPORT,28800SEC,SHA.
> Local Policy: ESP,3DES,1800SEC,100000K,XPORT,SHA.
>----------------------------------------------------------
>
>Once again, the ISAKMP SA is being established, but the IPSec is not.
>
>Here is what I get doing a "ifconfig" on my system...
>
>----------------------------------------------------------
>eth0 Link encap:Ethernet HWaddr 00:B0:D0:D1:DE:21
> inet addr:12.27.12.116 Bcast:12.27.12.127
Mask:255.255.255.224
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:13086 errors:0 dropped:0 overruns:0 frame:0
> TX packets:10941 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:1074064 (1.0 Mb) TX bytes:2108689 (2.0 Mb)
> Interrupt:11
>
>ipsec0 Link encap:Ethernet HWaddr 00:B0:D0:D1:DE:21
> inet addr:12.27.12.116 Mask:255.255.255.224
> UP RUNNING NOARP MTU:16260 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:72 overruns:0 carrier:0
> collisions:0 txqueuelen:10
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:12 errors:0 dropped:0 overruns:0 frame:0
> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:854 (854.0 b) TX bytes:854 (854.0 b)
>----------------------------------------------------------
>
>Notice how the ipsec0 interface is dropping all packets? That makes me
>think it's a routing problem. However, since he
can initiate the connection from his end with no problem, that doesn't
make much sense.
>
>"Whack" gives this as output...
>----------------------------------------------------------
>000 "worldpac": 12.27.12.116---12.27.12.97...63.89.49.214
>000 "worldpac": ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 0
>000 "worldpac": policy: PSK+ENCRYPT; interface: eth0; unrouted
>000 "worldpac": newest ISAKMP SA: #1; newest IPsec SA: #0; eroute
owner: #0
>000
>000 #2: "worldpac" STATE_QUICK_I1 (sent QI1, expecting QR1);
>EVENT_RETRANSMIT in 33s 000 #1: "worldpac" STATE_MAIN_I4 (ISAKMP SA
>established); EVENT_SA_REPLACE in 2759s; newest ISAKMP
>----------------------------------------------------------
>
>I'm noticing one perticular interesting line in my Pluto log..
>
>May 19 01:29:55 metro Pluto[868]: "worldpac" #1: ignoring informational
>payload, type NO_PROPOSAL_CHOSEN
>
>Here is the entire pluto log from a fresh boot, manually bringing up
>the connection, and then looking at a brand new,
empty upon boot /var/log/secure ...
>
>----------------------------------------------------------
[ snip ]
>----------------------------------------------------------
>
>Here is my current /etc/ipsec.conf ...
>
>----------------------------------------------------------
># /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
> # Debug-logging controls: "none" for (almost) none, "all" for
lots.
> klipsdebug=all
> plutodebug=all
> #klipsdebug=none
> #plutodebug=none
> # Use auto= parameters in conn descriptions to control startup
actions.
> # %search will process action specified in auto= for each conn
> plutoload=%search
> plutostart=%search
> # Close down old connection when new one using same ID shows
up.
> uniqueids=yes
>
># defaults for subsequent connection descriptions
># (mostly to fix internal defaults which, in retrospect, were badly
>chosen) conn %default
> keyingtries=0
> disablearrivalcheck=no
># authby=rsasig
># leftrsasigkey=%dns
># rightrsasigkey=%dns
>
>conn worldpac
> type=transport
> keyexchange=ike
> auth=esp
> authby=secret
> pfs=no
> # right and left are prettymuch interchangeable, but no reason to
> # try to switch them. "right" is the ip of THIS machine.
> # "rightnexthop" is the ip of the gateway machine between
> # "right" and the rest of the internet
> right=12.27.12.116
> rightnexthop=12.27.12.97
> left=63.89.49.214
> auto=add
>----------------------------------------------------------
>
>Any clue...? I'm going to experiment with my ipsec.conf and try
>combinations based off from his log result to see if the
policy is the problem. If not, then I'm going to double check my
routing. Any other help is much appreciated.
>
>Joshua Myner : MCP, MMCP
>Systems Administrator / Application Developer
>jmyner_at_gsite.com : (616)324-8231 Ext. 17
>Granite Solutions http://www.gsite.com
>
>_______________________________________________
>Users mailing list
>Users_at_lists.freeswan.org
>http://lists.freeswan.org/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:20:04 CEST