From: Sam Sgro (sam_at_freeswan.org)
Date: Thu Nov 28 2002 - 08:31:17 CET
-----BEGIN PGP SIGNED MESSAGE-----
On Wed, 27 Nov 2002, Vicente Vives wrote:
> Hi. I have a problem im my freeswan gw.
> Packets arrive to the gw but they don't know how to leave the gw:
> example, in /var/log/message:
> Nov 26 17:29:45 gateway kernel: VPN :IN=eth0 OUT=
> MAC=00:00:00:00:00:00:00:c0:49:44:ec:13:08:00 SRC=warrior_ip
> DST=gw_external_ip LEN=84 TOS=0x00 PREC=0x00 TTL=115 ID=14561 PROTO=UDP
> SPT=500 DPT=500 LEN=64
> where IN=public iface and OUT=should be private iface but it's empty.
Why should OUT be the private interface? If this is a negotiation attempt,
then the Roadwarriors means to communicate with the gw's external IP. If this
is the first packet in a negotiation attempt, it certainly seems reasonable.
Do you see any log messages that indicate FreeS/WAN receives this initiation
attempt?
> Yesterday I made this question to the #freeswan irc channel and some
> people told me that the problem could be the firewall rules.
> I think fireewall rules are correct:
> $IPTABLES -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT
> $IPTABLES -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
> $IPTABLES -A INPUT -p 50 -j ACCEPT
> $IPTABLES -A OUTPUT -p 50 -j ACCEPT
> $IPTABLES -A INPUT -p 51 -j ACCEPT
> $IPTABLES -A OUTPUT -p 51 -j ACCEPT
> $IPTABLES -A FORWARD -d $IF_LAN -i ipsec+ -j ACCEPT
> and somebody suggested me:
> $IPTABLES -A FORWARD -p udp --sport 500 --dport 500 -j ACCEPT
> and there is not any other rule which can drop freeswan paquets to/from
> gateway.
> This morning i asked this question to the channel and someone told me to
> modified iptables to don't drop anything (everything was accepted) but
> it didn't work.
> Do you have any suggestion?
(You don't see any messages complaining about rp_filter in your logs, do you?
That, plus firewall rules, can be the frequent cause of many packet loss
scenarios.)
Those are the standard rules we suggest people use; however, sometimes other
rules can be the cause of these problems. It's hard to tell without seeing all
of them. Heck, it's hard to tell even when you *can* see all of them! :)
I've found this trick helps when trying to diagnose firewall problems.
Start a ping attempt; use "iptables -L -n -v" twice, and diff the results.
Only the rules that a packet is falling afoul of will be flagged, as their
packet count will go up.
- --
Sam Sgro
sam_at_freeswan.org
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.
iQCVAwUBPeXGR0OSC4btEQUtAQGWTwQArHTnPEajIdY075v8FjEqteeZcwCpSihI
x443oylmreDtL4b7qc8UBJT1NHPws8zlo0Oxkq6vzBfasRhPLH/cHGVxR7YV/f4h
LRt8CkOLqWAQRQJPGYbpXVMUDucFKYqzsVTpFEONSvdRjNAjMFBT8x4TfFd13Inv
lvo5OoPIMQY=
=yecI
-----END PGP SIGNATURE-----
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.5 : Fri Nov 29 2002 - 05:21:11 CET