Shorewall users - Jun 2006 - problem setting up an ipsec vpn with 2.6.16 , racoon and shorewall

Hi list,

i''me trying to set up a vpn with racoon and 2.6.16.19 kernel and i got 
some problems.

here is my setup


debian sarge with kernel 2.6.16.19 with policy match support activated

iptables v1.3.5

shorewall 3.0.6

here is the shorewall show capabilities output:

Shorewall has detected the following iptables/netfilter capabilities:
   NAT: Available
   Packet Mangling: Available
   Multi-port Match: Available
   Extended Multi-port Match: Available
   Connection Tracking Match: Available
   Packet Type Match: Available
   Policy Match: Available
   Physdev Match: Not available
   IP range Match: Available
   Recent Match: Available
   Owner Match: Available
   Ipset Match: Not available
   CONNMARK Target: Not available
   Connmark Match: Not available
   Raw Table: Available
   CLASSIFY Target: Available


My network topo is :


Racoon
gateway
with shorewall
+ services http,smtp,etc
net iface:192.168.1.2--------------192.168.1.1 adsl 
routeur-->internet<---roadwarrior

behind routeur 192.168.2.56
local iface:192.168.100.1


my shorewall config is :

Tunnels
#TYPE                   ZONE    GATEWAY         GATEWAY
#                                               ZONE
ipsec           net     0.0.0.0/0   vpn


Zones
###############################################################################
#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
loc     ipv4
net     ipv4
vpn     ipsec       mode=tunnel



Hosts
###############################################################################
#ZONE   HOST(S)                                 OPTIONS
vpn     eth0:0.0.0.0/0


Policy
############################################################################
#SOURCE         DEST            POLICY          LOG             LIMIT:BURST

snip....

vpn     fw      ACCEPT     $LOG
vpn     loc     ACCEPT     $LOG
loc     vpn     ACCEPT     $LOG
fw      vpn     ACCEPT     $LOG
vpn     net     ACCEPT     $LOG

snip...

Interfaces
#ZONE   INTERFACE       BROADCAST       OPTIONS
net eth0    detect
loc eth1    detect  dhcp

Masq
###############################################################################
#INTERFACE              SUBNET          ADDRESS         PROTO   PORT(S) 
IPSEC
eth0:!192.168.2.56/32    eth1




I can start my ipsec tunnel ok, SA is ok , but i can''t route any
traffic
in the tunnel
each time i try a ping or anything else , i got those lines in firewall 
logs:

Jun  2 10:18:51 simon Shorewall:INPUT:REJECT: IN=eth0 OUT= 
MAC=00:50:22:80:8d:03:00:16:ae:0c:bb:8a:08:00  SRC=192.168.2.56 
DST=192.168.100.1 LEN=48 TOS=00 PREC=0x00 TTL=128 ID=56865 CE DF 
PROTO=TCP SPT=2271 DPT=143 SEQ=2400887515 ACK=0 WINDOW=65535 SYN URGP=0
Jun  2 10:18:51 simon Shorewall:INPUT:REJECT: IN=eth0 OUT= 
MAC=00:50:22:80:8d:03:00:16:ae:0c:bb:8a:08:00  SRC=192.168.2.56 
DST=192.168.100.1 LEN=60 TOS=00 PREC=0x00 TTL=128 ID=56867 CE PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=31232
Jun  2 10:18:51 simon Shorewall:OUTPUT:REJECT: IN= OUT=eth0 MAC= 
SRC=192.168.100.1 DST=192.168.2.56 LEN=88 TOS=00 PREC=0x00 TTL=64 
ID=11255 PROTO=ICMP TYPE=3 CODE=1
Jun  2 10:18:56 simon Shorewall:INPUT:REJECT: IN=eth0 OUT= 
MAC=00:50:22:80:8d:03:00:16:ae:0c:bb:8a:08:00  SRC=192.168.2.56 
DST=192.168.100.1 LEN=60 TOS=00 PREC=0x00 TTL=128 ID=56871 CE PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=31488


I seems to me that shorewall doesn''t detect that traffic from and to 
192.168.2.56 belongs to vpn zone

Any help would be greatly appreciated

thanks in advance

Xavier

Xavier wrote:

> 
> 
> I seems to me that shorewall doesn''t detect that traffic from and
to
> 192.168.2.56 belongs to vpn zone
It''s not Shorewall''s job to detect such traffic -- rather that
is the
responsibility of the Netfilter rules that Shorewall instantiates during
"shorewall start". As is clearly explained on the Shorewall home page,
once
"shorewall start" completes there is no Shorewall code running in your
system
whatsoever.
> 
> Any help would be greatly appreciated
> 
First you must help us by providing the information we ask for at
http://www.shorewall.net/support.htm (e.g the output of "shorewall
dump" after
one of these failures). In addition, the output of "setkey -D" would
also be
helpful.

Thanks,
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Hello Shorewall-users,

This is probably not the place to ask this question and if I have stepped 
out of line here, please just disregard my question as I will not ask again. 
I have searched around looking for answers and so far I have not found any 
and thought the expert Tom might have a simple answer.

I''ve been a fan of Shorewall for years and love the simplicity of this 
versatile program for managing and installing a great set of firewall rules. 
I''ve also added some of my own touches to block "greedy" or
should I say
"robotic" traffic to our web servers that are there to do little more
than
steal bandwidth. While our greedy rule is working well, it''s bit
difficult
to maintain with tens of millions of connections a day. Basically this is 
how we are now using this:

/etc/shorewall/rules

# Setup the the greedy rule
/bin/dmesg -n 3
/sbin/iptables -N greedy
/sbin/iptables -I INPUT -j greedy

Then we have a program that is running every 5 minutes or so that detects 
the "greedy" users from log files. This program basically does this:

# 1st flush the greedy rule of old entries and allow all greedy users back
iptables -F greedy
# find the next set of greedy users and add them to our greedy rule using 
the following
iptables -I greedy -p tcp --dport 80 -s 1.2.3.4 -j DROP


Now the big problem here is that we allow the greedy back every 5 minutes. 
Instead what I would rather do is block the greedy IP for X number of 
seconds, minutes, days etc.. based on how many times this greedy user was 
detected over a period of time (maintained in a database file).

I don''t want to write a speed limit rule to deny all port 80 traffic as
this
will return false positives. A Web page consists of html, images, external 
javascript and CSS files and ?. So if you were to detect total requests by 
IP based on port 80 requests, you could easily block valid users.

Is there a TTL based iptables rule that will work here?

Thanks in advance,
John

J and T wrote:
> Is there a TTL based iptables rule that will work here?
>
> Thanks in advance,
> John
>   
    John,

    There is a python script we use to detect dictionary attacks against 
our mail servers. It essentially looks for the mail server (sendmail) to 
throttle the traffic based on cf config/log, and scripts the changes 
into/out of IP tables.

    It does time, track, and release IP bans when scheduled. It runs via 
cron. You''ll need to make some changes to the code to make it work for 
your purposes. If you want a copy- just speak up.

--
Michael Cozzi
cozzi@cozziconsulting.com

Hi Michael Cozzi,

I don''t need the entire script, just the rule. If you''re not
sure the rule,
I''ll take the script and look it over to see if there''s a rule
that will
work. I''ve seen a similar rule based on # of connections for a period
of
time:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent 
--set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent 
--update --seconds 60 --hitcount 4 -j DROP

Which basically detects if the IP address has sent a packet in the past 60 
seconds and the IP address has sent more than 4 packets in total. If so, 
they are dropped. What I need is more of a TTL rule rather than a connect 
detection and drop scheme.

Thanks!
John
>J and T wrote:
> > Is there a TTL based iptables rule that will work here?
> >
> > Thanks in advance,
> > John
> >
>
>     John,
>
>     There is a python script we use to detect dictionary attacks against
>our mail servers. It essentially looks for the mail server (sendmail) to
>throttle the traffic based on cf config/log, and scripts the changes
>into/out of IP tables.
>
>     It does time, track, and release IP bans when scheduled. It runs via
>cron. You''ll need to make some changes to the code to make it work
for
>your purposes. If you want a copy- just speak up.
>
>--
>Michael Cozzi
>cozzi@cozziconsulting.com
>
>
>_______________________________________________
>Shorewall-users mailing list
>Shorewall-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/shorewall-users

J and T wrote:
> What I need is more of a TTL rule rather than a connect 
> detection and drop scheme.
The only thing remotely similar is the ''iptree'' ipset which
allows IP
addresses to be added with a timeout. So if you created a
''greedy'' ipset
of type iptree then you could have this rule:

iptables -I INPUT -p tcp --dport 80 -m set --set greedy src -j DROP

And you could add ip addresses to the ''greedy'' set using the
ipset utility:

ipset -A greedy <ip address>%<seconds>

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Thanks Tom,

I appreciate the feedback and certainly don''t expect you to support
this
since it really has nothing to do with shorewall (which I absolutely love). 
Anyone looking for a decent firewall I send them your way always.

I''ll had a look at the ipset utility and it seems very interesting and
could
be fantastically efficient. They don''t include a tar ball so
I''ll download
each source file and give it a shot.

During my quest to help with my problem, I put together a rule (which my 
iptables does not yet support). What are your thoughts about something like 
this?:

/sbin/iptables -N greedy
/sbin/iptables -I INPUT -j greedy --update --seconds 600 -j DROP
/sbin/iptables -A INPUT -p tcp --dport 80 -s 1.2.3.4 -m --set greedy --set 
-j DROP

(OR maybe this is more correct):

/sbin/iptables -N greedy
/sbin/iptables -D INPUT -m greedy --update --name POUNDER --seconds 600 -j 
DROP
/sbin/iptables -A INPUT -p tcp -s 1.2.3.4 --dport 80 -m greedy --name 
POUNDER --set -j DROP

My syntax may be completely wrong (I really need to spend a day learning 
iptables). But if the syntax were right, would this not drop all requests 
from the IP address 1.2.3.4 until this "greedy" user was quite for at
least
5 minutes? If this is true, it could solve a lot of attacks by denying users 
access forever if they continue to POUND port 80. If they stop for a minimum 
of 5 minutes, they are allowed to return, but then if I catch the greedy 
user again, he''s put back in the greedy pool. My guess is that the
ipset
utility could do the same thing and possibly do it more efficiently.

Any thoughts about this?

Again, you are not obligated to reply. I just know you''re the master,
John
>J and T wrote:
> > What I need is more of a TTL rule rather than a connect
> > detection and drop scheme.
>
>The only thing remotely similar is the ''iptree'' ipset
which allows IP
>addresses to be added with a timeout. So if you created a
''greedy'' ipset
>of type iptree then you could have this rule:
>
>iptables -I INPUT -p tcp --dport 80 -m set --set greedy src -j DROP
>
>And you could add ip addresses to the ''greedy'' set using
the ipset utility:
>
>ipset -A greedy <ip address>%<seconds>
>
>-Tom
>--
>Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
>Shoreline,     \ http://shorewall.net
>Washington USA  \ teastep@shorewall.net
>PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
><< signature.asc >>




>_______________________________________________
>Shorewall-users mailing list
>Shorewall-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/shorewall-users

On 6/2/06, Xavier <xav@spotk.net> wrote:
> i''me trying to set up a vpn with racoon and 2.6.16.19 kernel and i
got
> some problems.
> [snip]
> I seems to me that shorewall doesn''t detect that traffic from and
to
> 192.168.2.56 belongs to vpn zone
Hi Xavier

First, have you written the relevant SPDADDs in /etc/ipsec-tools.conf?

Second, I have seen people recommending using the unstable version of
ipsec-tools, rather than the Sarge version.

Third, don''t use racoon-tool (the Debian script to make setting up
racoon easier).  It has not been properly maintained for a while.


Rune

Tom Eastep a écrit :
> Xavier wrote:
>
>   
> First you must help us by providing the information we ask for at
> http://www.shorewall.net/support.htm (e.g the output of "shorewall
dump" after
> one of these failures). In addition, the output of "setkey -D"
would also be
> helpful.
>
> Thanks,
> -Tom
>   
Hi,  and thanks for your answer,
here is attached a tarball containing the 2 asked dumps , if you can help me

Thanks

Xavier

Xavier wrote:
> Tom Eastep a écrit :
>> Xavier wrote:
>>
>>   First you must help us by providing the information we ask for at
>> http://www.shorewall.net/support.htm (e.g the output of "shorewall
>> dump" after
>> one of these failures). In addition, the output of "setkey
-D" would
>> also be
>> helpful.
>>
>> Thanks,
>> -Tom
>>   
> Hi,  and thanks for your answer,
> here is attached a tarball containing the 2 asked dumps , if you can
> help me
>
a) Either you don''t have the LOGFILE variable in shorewall.conf set
properly or you didn''t reproduce the problem before capturing the dump
-- the "shorewall dump" output shows no log messages.

b) The dump is from a different configuration than what you posted
originally -- there are no ipsec rules whatsoever in this dump (the
''vpn'' zone is not an ipsec zone). If you believe that the
configurations
are the same then please trace "shorewall restart" (shorewall trace
restart 2> /tmp/trace) and post the trace file as a compressed attachment.

c) The original report indicated that traffic from 192.168.2.56 to
192.168.100.1 was being dropped. The only addresses covered by the
current SAs are 99.33.94.32 and 192.168.1.2

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Tom Eastep wrote:
> 
> b) The dump is from a different configuration than what you posted
> originally -- there are no ipsec rules whatsoever in this dump (the
> ''vpn'' zone is not an ipsec zone). If you believe that the
configurations
> are the same then please trace "shorewall restart" (shorewall
trace
> restart 2> /tmp/trace) and post the trace file as a compressed
attachment.
I notice from your original post that you defined no firewall zone in
/etc/shorewall/zones. This indicates that you may have IPSECFILE=ipsec
in your shorewall.conf file which will cause Shorewall to ignore all but
the first column of entries in /etc/shorewall/zones. That is for
compatibility with Shorewall versions prior to 3.0.

If this is the case, then you need to:

a) Change shorewall.conf to include IPSECFILE=zones. Also, if you have
   FW=fw in shorewall.conf, comment out that line.

b) Add ''fw'' as a firewall zone to /etc/shorewall/zones:

###############################################################################
#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
loc     ipv4
net     ipv4
vpn     ipsec       mode=tunnel

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Tom Eastep a écrit :
> I notice from your original post that you defined no firewall zone in
> /etc/shorewall/zones. This indicates that you may have IPSECFILE=ipsec
> in your shorewall.conf file which will cause Shorewall to ignore all but
> the first column of entries in /etc/shorewall/zones. That is for
> compatibility with Shorewall versions prior to 3.0.
>
> If this is the case, then you need to:
>
> a) Change shorewall.conf to include IPSECFILE=zones. Also, if you have
>    FW=fw in shorewall.conf, comment out that line.
>
> b) Add ''fw'' as a firewall zone to /etc/shorewall/zones:
>
>
###############################################################################
> #ZONE   TYPE            OPTIONS         IN                      OUT
> #                                       OPTIONS                 OPTIONS
> fw      firewall
> loc     ipv4
> net     ipv4
> vpn     ipsec       mode=tunnel
>
> -Tom
>   
Yep :)
And everything is fine thanks to your advices :)

thanks a lot for your support, next time i will read docs more 
thoroughly before posting.

Cheers

Xavier