[ previous ] [ next ] [ threads ]
 
 From:  Michael Stecher <Michael dot Stecher at cib dot de>
 To:  "m0n0wall at lists dot m0n0 dot ch" <m0n0wall at lists dot m0n0 dot ch>
 Subject:  AW: AW: [m0n0wall] Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME notification
 Date:  Fri, 28 Nov 2008 17:05:48 +0100
I've found out the problem: we're using a 10.0.0.0 Class A net on m0n0wall OPT interface (endpoint
of the tunnel) but only a /29 subnet for the ipsec tunnel. For each subnet we've got one proxy ARP
entry in m0n0wall configuration for the respective subnets gateway. In the near future we want to
establish more of these subnets with a own ipsec tunnel to a specific customer so it's not possible
to use current ipsec subnet for OPT interface. The subnets should be separated from each other (we
do this with firewall rules and managed switches).

M0n0wall adds ipsec firewall rules for OPT interface IP address (/32), but not for the specific
tunnels.
...
@18 pass out quick on vr2 proto udp from 10.0.0.1/32 port = isakmp to any keep frags
@19 pass out quick on vr2 proto udp from 10.0.0.1/32 port = sae-urn to any keep frags
@20 pass out quick on vr2 proto esp from 10.0.0.1/32 to any keep frags
@21 pass out quick on vr2 proto ah from 10.0.0.1/32 to any keep frags
...
@32 pass in quick on vr2 proto udp from any to 10.0.0.1/32 port = isakmp keep frags
@33 pass in quick on vr2 proto udp from any to 10.0.0.1/32 port = sae-urn keep frags
@34 pass in quick on vr2 proto esp from any to 10.0.0.1/32 keep frags
@35 pass in quick on vr2 proto ah from any to 10.0.0.1/32 keep frags

Is there an easy reason to add those rules for our subnets (proxy ARP) gateways? I've tried with
<shellcmd> and ipf -f but this is really exhausting and I think not very fail-safe too.

Have many thanks for your help.

Kind regards,
Michael





Von: Eric Boudrand [mailto:eric at boudrand dot net]
Gesendet: Mittwoch, 26. November 2008 23:12
An: m0n0wall at lists dot m0n0 dot ch
Betreff: Re: AW: [m0n0wall] Problems with IPSec Site to Site Tunnel: ignore RESPONDER-LIFETIME
notification

Hi,

> I've made some other detection: if the peer side starts the tunnel
> first I've got following log entry:
> Nov 26 10:26:48 racoon: NOTIFY: the packet is retransmitted by
> x.x.x.x[500].
> Nov 26 10:26:38 racoon: INFO: received Vendor ID:
> draft-ietf-ipsec-nat-t-ike-02
> Nov 26 10:26:38 racoon: INFO: received Vendor ID:
> draft-ietf-ipsec-nat-t-ike-03
> Nov 26 10:26:38 racoon: INFO: received Vendor ID:
> draft-ietf-ipsec-nat-t-ike-07
> Nov 26 10:26:38 racoon: INFO: begin Identity Protection mode.
> Nov 26 10:26:38 racoon: INFO: respond new phase 1 negotiation:
> x.x.x.x[500]<=>x.x.x.x[500]
>
> It look like the peer didn't receive a needed packet from our side,
> right?

draft-ietf-ipsec-nat-t-ike-07... The RFC 3947 was published in January
2005 and it is the reference document. The firmware of the Cisco does
not implement it. Anyway, that is details. There are no big difference
between this draft and the RFC. I think the remote gateway dropped the
response from the racoon. You should take a look to the Cisco logs.

I do not like racoon logs because some basic information are missing. In
main mode you have 6 exchanges and in Quick Mode 3 exchanges. You can
deduce very easily configuration error from the point at which the
negotiation failed. In this log, a packet is retransmitted in phase 1,
but which one ? Packet with Security Association payload (1rst and 2nd
exchanges) ? Or packet with ID payload (5th and 6th exchanges) ? Is
there a problem when using UDP port 4500 in the 5th and 6th exchanges ?
I do not think it is a configuration issue, because it worked. Cisco
logs will be helpful.

Regards.
-



---------------------------------------------------------------------
To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch