Very interesting, Tom... Thanks for taking the time to get into more detail.

I have modified my rules back to your original suggestion, however, I still
have one question.

[snip]
In order for either of rules [2] to have been invoked, the ORIGINAL
destination IP would have had to have been in your local network; clearly
that is never going to be the case (my point from the last post). You may
as well remove the rules since they will never do anything.
[end snip]

These rules did do "something". They made it possible for me to bring up the
tunnel. I understand the importance of doing it as per your example, I
changed my rules accordingly. If I understand you correctly, based on the
snip above, my rules shouldn't have worked at all?

Respectfully,
Eric

-----Original Message-----
From: Tom Eastep [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 9:44 AM
To: Eric B Kiser
Cc: [EMAIL PROTECTED]
Subject: RE: [leaf-user] Testing IPsec pass-through


On Fri, 3 May 2002, Eric B Kiser wrote:

> What you suggested was this [1]:
>
> ACCEPT net loc:<local endpoint ip> udp 500 - all
> ACCEPT net loc:<local endpoint ip> 50  -   - all
>
> I decided not to include the endpoint ip address because I wanted be able
to
> use any machine on my local network. So... I did this [2]:
>
> ACCEPT net loc udp 500
> ACCEPT net loc 50  all
>
> results from [1] this connection was only up for a couple of minutes.
>
> # shorewall show net2loc
> Shorewall-1.2.8 Chain net2loc at firewall - Thu May  2 15:42:01 UTC 2002
>
> Chain net2loc (1 references)
>  pkts bytes target     prot opt in     out     source
> destination
>    27  4277 ACCEPT     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0          state RELATED,ESTABLISHED
>     0     0 ACCEPT     udp  --  *      *       0.0.0.0/0
> 192.168.1.10       state NEW udp dpt:500
>     1    88 ACCEPT     esp  --  *      *       0.0.0.0/0
> 192.168.1.10       state NEW
>     0     0 net2all    all  --  *      *       0.0.0.0/0
> 0.0.0.0/0
>
> results from [2] this connection was up for 25 minutes.
>
> # shorewall show net2loc
> Shorewall-1.2.8 Chain net2loc at firewall - Thu May  2 16:12:20 UTC 2002
>
> Chain net2loc (1 references)
>  pkts bytes target     prot opt in     out     source
> destination
>  1331  156K ACCEPT     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0          state RELATED,ESTABLISHED
>     0     0 ACCEPT     udp  --  *      *       0.0.0.0/0
> 0.0.0.0/0          state NEW udp dpt:500
>     0     0 ACCEPT     esp  --  *      *       0.0.0.0/0
> 0.0.0.0/0          state NEW
>     0     0 net2all    all  --  *      *       0.0.0.0/0
> 0.0.0.0/0
>
> The only difference here are the esp (protocol: 50) packets that were
> logged. Is this the difference that you were expecting me to find. I am
not
> in control of the other end. Would you typically expect that a rekeying
> attempt would have been made in the 25 minutes that I had left the tunnel
> up?
>

Depends on how you have set the re-key interval for the tunnnel. Also,
remember that re-keying only involves the UDP "connection". I no longer
have any IPSEC tunnels so I don't have immediate access to the docs to see
what the default interval is.

In order for either of rules [2] to have been invoked, the ORIGINAL
destination IP would have had to have been in your local network; clearly
that is never going to be the case (my point from the last post). You may
as well remove the rules since they will never do anything.

The basic problem is that IPSEC tunnels are quiet when there is no traffic
and the re-keying interval hasn't expired. In that time, the connection
tracking entries created when the local endpoint first sent packets to the
remote one will time out. Then, if a packet is received from the remote
end-point, the RELATED,ESTABLISHED rule (first Shorewall-generated rule in
both cases) won't match the incoming packet and the packet will be
rejected.

As long as the local endpoint speaks first after such a quiet time,
everything works -- otherwise, it may not.

By having rules [1], if the remote end sends a packet (either ESP or
UDP/500) and there is no matching connection-tracking entry, the
appropriate rule will:

a) Re-establish a connection tracking entry between the end-points for
that protocol[/port]; and
b) Route the packet to the appropriate local host.

If your tunnels are fairly busy when they are up and you have a short
re-key interval, you should be fine without any IPSEC-related rules. If
you leave these tunnels up overnight with no traffic, you will almost
certainly encounter problems.

-Tom
--
Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ [EMAIL PROTECTED]



_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]

------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to