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
