Shorewall users - Jan 2003 - VPN hardware?

I have a NetGear FV318 living in my DMZ, with one of its LAN-ports
living in my LOC zone. What rules are needed in shorewall to allow a
certain subnet to make connections to this device from the net zone? 

Do I define it as a tunnel in shorewall/tunnels, or do I just allow some
selected traffic to the DMZ IP? I am not sure which of the docs are
right for me in this case?

--On Friday, January 03, 2003 01:29:53 PM +0100 Jan Johansson 
<jan.johansson@nwl.se> wrote:
>
> I have a NetGear FV318 living in my DMZ, with one of its LAN-ports
> living in my LOC zone. What rules are needed in shorewall to allow a
> certain subnet to make connections to this device from the net zone?
>
> Do I define it as a tunnel in shorewall/tunnels, or do I just allow some
> selected traffic to the DMZ IP? I am not sure which of the docs are
> right for me in this case?
>
All you need is a rule.

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net

>All you need is a rule.
Well, currently I am allowing all net->that IP, but that seems a bit
frivolous?

Well, after finding a bug in NetGear FVS318 (Don''t try to use \ in a
SharedKey, it wont work). The tunnel is up. However, something else
isn''t quite right.

I added a route on my shorewall box 

192.168.224.0   192.168.221.221 255.255.255.0   UG    0      0        0
eth1

I have a system on the remote side of the tunnel pinging a system in my
loc zone. But it seems this is a one way street?

Jan  3 16:34:49 argus kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1
SRC=192.168.221.200 DST=192.168.224.2 LEN=60 TOS=0x00 PREC=0x00 TTL=127
ID=25057 PROTO=ICMP TYPE=0 CODE=0 ID=512 SEQ=59909

If I however add a route on 192.168.221.200 everything works just dandy.
What am I missing on my shorewall(1.3.12) config? (Enclosed below)

Zones
#ZONE   DISPLAY         COMMENTS
net     Net             Internet 
loc     Local           Local networks
dmz     DMZ             Demilitarized zone
dmb     DMB             Second DMZ
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

Policy
#SOURCE         DEST            POLICY          LOG LEVEL
LIMIT:BURST
loc             net             ACCEPT

#$FW    all     ACCEPT

net             all             DROP            info
all             all             REJECT          info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

Rules (they are a mess, I know)
#
#FW Rules
#Allow Time
ACCEPT  $FW     net     tcp     time
#
#Allow LOC->FW
ACCEPT  loc     $FW     tcp     ssh,www
#
#Allow FW->Net
ACCEPT  $FW     net     tcp     domain,www
ACCEPT  $FW     net     udp     domain
#
#Allow FW->DMZ
ACCEPT  $FW     dmz:213.212.33.20       tcp     smtp
#
#Allow FW->LOC
ACCEPT  $FW     loc     udp     snmp,snmp-trap


#
#DMZ Rules
ACCEPT  dmz     net     tcp     domain,www,https,smtp,auth,ftp,time,81
ACCEPT  dmz     net     udp     domain,www,https,time
ACCEPT  dmz     loc     udp     domain
ACCEPT  dmz     loc     tcp     domain

#
#VPN admin
ACCEPT  loc     dmz     tcp     8080

#
#MAIL
#Open for smtp in.
ACCEPT  net     dmz:213.212.33.20       tcp     smtp
#
#Open for Orrekulla to smtp
ACCEPT  net:213.67.31.0/24      dmz:213.212.33.20 tcp     smtp


#
#Open for mail to DMZ
ACCEPT  loc     dmz:213.212.33.20       tcp     smtp

#
#Redirect mail from loc -> smtp
#DNAT   loc     dmz:213.212.33.20       tcp     smtp
#
#Backup via Dataphone.
#ACCEPT loc     net:212.37.1.51 tcp     smtp    -       195.163.130.58
#
#Allow SMTP-relay -> Mailserver
ACCEPT  dmz:213.212.33.20       loc:192.168.221.202     tcp     smtp
#
#
#
#Accept to POP-server from TrIPNet and Telia/ADSL
DNAT    net:217.28.207.0/24,195.100.170.0/24,213.67.31.0/24
loc:192.168.221.202     tcp     pop3




#PC Anywhwere -> KSD server
#DNAT   net:209.10.140.0/24     loc:192.168.221.6       tcp     5631
#DNAT   net:209.10.140.0/24     loc:192.168.221.6       udp     5632
#DNAT   net     loc:192.168.221.6       tcp     5631
#DNAT   net     loc:192.168.221.6       udp     5632

#
#LOC -> DMZ
ACCEPT  loc     dmz     tcp     www,ssh,https,81


#
#NET -> DMZ
ACCEPT  net     dmz:213.212.33.20       tcp     www

#
#Waldorf
ACCEPT  net     dmz:213.212.33.23       tcp
www,https,81,ssh,pop3,pop3s,smtp

#
#PPTP
DNAT           net:213.67.241.162/32,212.151.0.0/16
loc:192.168.221.200     tcp     1723
DNAT           net:213.67.241.162/32,212.151.0.0/16
loc:192.168.221.200     47      -

#
#IPsec / VPN
#Time
ACCEPT          dmz:213.212.33.22/32
net:131.107.1.10/32,192.43.244.18/32 udp        123
ACCEPT          net     dmz:213.212.33.22       all 
ACCEPT          dmz:213.212.33.22       net     all

#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

--On Friday, January 03, 2003 04:38:11 PM +0100 Jan Johansson 
<jan.johansson@nwl.se> wrote:
>> All you need is a rule.
>
> Well, currently I am allowing all net->that IP, but that seems a bit
> frivolous?
>
> Well, after finding a bug in NetGear FVS318 (Don''t try to use \ in
a
> SharedKey, it wont work). The tunnel is up. However, something else
> isn''t quite right.
>
> I added a route on my shorewall box
>
> 192.168.224.0   192.168.221.221 255.255.255.0   UG    0      0        0
> eth1
>
Jan, This isn''t a puzzle mailing list -- it is a mailing list to get
help
with Shorewall problems. Your have given us:

a) A fragment of your routing table.
b) A Shorewall log message.
c) A vague statement that if you add some unspecified route somewhere in 
the network, the problem (whatever it is) goes away.
d) Part of your Shorewall config but you omitted the interfaces file so we 
don''t even have a clue as to which interface goes to which zone.

And then you ask us what''s wrong.

I''m sorry -- I don''t have the time or energy to try to solve
this riddle.

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net

>Jan, This isn''t a puzzle mailing list -- it is a mailing list to
get
help 
>with Shorewall problems. Your have given us:
Lets specify.

>a) A fragment of your routing table.
Complete route of shorewall box.

argus:/etc/shorewall# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
smtp.nwl.se     *               255.255.255.255 UH    0      0        0
eth2
213.212.33.22   *               255.255.255.255 UH    0      0        0
eth2
waldorf-ng.mupp *               255.255.255.255 UH    0      0        0
eth2
213.212.33.16   *               255.255.255.240 U     0      0        0
eth0
192.168.224.0   192.168.221.221 255.255.255.0   UG    0      0        0
eth1
192.168.221.0   *               255.255.255.0   U     0      0        0
eth1
192.168.223.0   *               255.255.255.0   U     0      0        0
eth3
192.168.222.0   *               255.255.255.0   U     0      0        0
eth2
default         dslpipe.nwl.se  0.0.0.0         UG    0      0        0
eth0
argus:/etc/shorewall#
>b) A Shorewall log message.
Well, it was relevant in as such as the pings from the remote network
(192.168.224.0/24) was infact reaching my LOC-zone (192.168.221.0/24)
But answers where blocked by shorewall. The log messages conforms 1:1
with the pings sent by the remote machine.
>c) A vague statement that if you add some unspecified route somewhere
in 
>the network, the problem (whatever it is) goes away.
If I do "route add 192.168.224.0 mask 225.255.255.0 192.168.221.221"
on
any windows box in the loc-zone, I can ping the remote net, and get
responses.
(linuxese for that route is "route add -net 192.168.224.0 gw
192.168.221.221")
>d) Part of your Shorewall config but you omitted the interfaces file so
we 
>don''t even have a clue as to which interface goes to which zone.
Cripe. I really did thought the interface was there, well, here it is
now.

#ZONE    INTERFACE      BROADCAST       OPTIONS
net     eth0    detect  norfc1918
loc     eth1    detect
dmz     eth2    detect
dmb     eht3    detect
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

and ifconfig

eth0      Link encap:Ethernet  HWaddr 52:54:05:F4:CD:F9  
          inet addr:213.212.33.18  Bcast:213.212.33.31
Mask:255.255.255.240

eth1      Link encap:Ethernet  HWaddr 00:00:E8:84:EB:27  
          inet addr:192.168.221.7  Bcast:192.168.221.255
Mask:255.255.255.0

eth2      Link encap:Ethernet  HWaddr 00:09:5B:06:21:2B  
          inet addr:192.168.222.1  Bcast:192.168.222.255
Mask:255.255.255.0

eth3      Link encap:Ethernet  HWaddr 00:09:5B:06:13:00  
          inet addr:192.168.223.1  Bcast:192.168.223.255
Mask:255.255.255.0


So basically. On eth1 I have a C-class network which is my LOC-zone. In
that LOC-zone is a router that knows how to talk to 192.168.224.0 which
is a VPN-enpoint at a remote office. 

If a workstation in the LOC-zone talks directly to the VPN-router, all
is fine and well. 

If I use the shorewall box as the router, traffic gets blocked.

>I''m sorry -- I don''t have the time or energy to try to
solve this
riddle.

I hope I have clarified the black spots now?

And the last piece of the puzzle:

#ADDRESS                INTERFACE       EXTERNAL        HAVEROUTE
213.212.33.20           eth2            eth0            no
213.212.33.22           eth2            eth0            no
213.212.33.23           eth2            eth0            no
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

.22 is the external IP of the VPN router.

--On Friday, January 03, 2003 04:38:11 PM +0100 Jan Johansson 
<jan.johansson@nwl.se> wrote:
>> All you need is a rule.
>
> Well, currently I am allowing all net->that IP, but that seems a bit
> frivolous?
>
> Well, after finding a bug in NetGear FVS318 (Don''t try to use \ in
a
> SharedKey, it wont work). The tunnel is up. However, something else
> isn''t quite right.
>
Ok -- so I like puzzles....

Here is what I think you are saying

       Remote system
        |
        |
       FW---- Netgear
        |        |
       Switch ---
        |
      local System


You establish a tunnel from the remote system to the netgear then try to 
ping the local system from the remote system. The echo request goes to the 
FW to the Netgear to the local system but the echo reply is going directly 
to the firewall where it is being rejected. If you add a route on the local 
system to the remote system via the Netgear then it works.

Is that your problem?

If so, THAT''S THE WAY IP WORKS. IP packets aren''t like
spawning Salmon;
they don''t carry a genetic code that tells their children (response 
packets) the way back to the spawning ground.

In your case, the response packets are routed based on the routing table IN 
THE LOCAL SYSTEM.

You have no choice but to add the appropriate route in each of the local 
systems.

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net

>The interface for dmb is "eht3".  Should that perhaps be
"eth3"?
Right you are. But, eth3/dmb isn''t used for anything as of yet. But I
thank you just the same.

Hm, shouldn''t "shorewall check" notice a syntax error like
that?

>Ok -- so I like puzzles....
>
>Here is what I think you are saying
>
>       Remote system
>        |
>        |
>       FW---- Netgear
>        |        |
>       Switch ---
>        |
>      local System
Correct.
>You establish a tunnel from the remote system to the netgear then try
to 
>ping the local system from the remote system. The echo request goes to
the 
>FW to the Netgear to the local system but the echo reply is going
directly 
>to the firewall where it is being rejected. If you add a route on the
local 
>system to the remote system via the Netgear then it works.
>
>Is that your problem?
>
>If so, THAT''S THE WAY IP WORKS. IP packets aren''t like
spawning Salmon;
>they don''t carry a genetic code that tells their children (response
>packets) the way back to the spawning ground.
Well, yes, but.. call me stupid here... But since FW knows how to route
back to the remote site, and all local system uses FW as their default
GW. Shouldn''t that solve the problem.. if not.. I must be missing
something, because I actually thought I knew routing?

>In your case, the response packets are routed based on the routing
table IN 
>THE LOCAL SYSTEM.
Which looks like this


(I know you do not like windows, so here is how it looks in a local
Penguin)

hooch:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
192.168.221.0   0.0.0.0         255.255.255.0   U     0      0        0
eth0
0.0.0.0         192.168.221.7   0.0.0.0         UG    0      0        0
eth0
hooch:~#
>You have no choice but to add the appropriate route in each of the
local 
>systems.
What am I missing that makes that the case? I am sorry if I come through
like a total dimwit here :-/ I mean, shouldn''t the LOC-systems send
that
package to default GW, which should send it off to the VPN router? I
know I am tired, and I have doing inventory of 10.000 pallets of
Japanese consumer electronics, and I am drooling over some of that
stuff.. But, this route should work?

--On Friday, January 03, 2003 05:13:25 PM +0100 Jan Johansson 
<jan.johansson@nwl.se> wrote:
>> The interface for dmb is "eht3".  Should that perhaps be
"eth3"?
>
> Right you are. But, eth3/dmb isn''t used for anything as of yet.
But I
> thank you just the same.
>
> Hm, shouldn''t "shorewall check" notice a syntax error
like that?
>
No -- ''eht3'' is valid as an interface name and Shorewall
doesn''t require
interfaces to be defined at the time it starts/checks. In my configuration, 
I have an interface called ''texas'' but I could have just as
easily named it
eht3.

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net

>No -- ''eht3'' is valid as an interface name and Shorewall
doesn''t
require 
>interfaces to be defined at the time it starts/checks. In my
configuration, 
>I have an interface called ''texas'' but I could have just
as easily
named it 
>eht3.
I stand corrected. But that probably would have bitten me eventually.

> Hm, shouldn''t "shorewall check" notice a syntax error
like that?
I think it shouldn''t

interfaces can have every name you want 

so eht3 can be a valid interface name :-)

Niels

And the answer to the riddle is: Windows(tm).

Tom, I am sorry for grating your nerves with windows boxes. I tried to
ping the remote endpoint from the Linux box previously mentioned.. and
it was an instant success. 

Now, trying ''real services'' I got a more logical error: (like)
Jan  3 17:24:55 argus kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1
SRC=192.168.221.207 DST=192.168.224.2 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=45301 DF PROTO=TCP SPT=3579 DPT=8080 WINDOW=64240 RES=0x00 SYN URGP=0

This is ofcource since I had no Loc->Loc Accept policy. 

The funny(?) thing though is that I tried pinging from the windows
system again, same result as before.

The windows box was still clueless, so I cleared all network related
caches I knew of in Windows without success.

Now I added the Loc/Loc policy, and restarted shorewall. And the windows
box was immediately happy with the situation. 

I have _NO_ idea what windows was up to here, but it was no good.

Tom, what can I say, I am sorry for using Windows to debug :)

Have a nice weekend.

--On Friday, January 03, 2003 05:37:10 PM +0100 Jan Johansson 
<jan.johansson@nwl.se> wrote:
> And the answer to the riddle is: Windows(tm).
>
> Tom, I am sorry for grating your nerves with windows boxes. I tried to
> ping the remote endpoint from the Linux box previously mentioned.. and
> it was an instant success.
>
> Now, trying ''real services'' I got a more logical error:
(like)
> Jan  3 17:24:55 argus kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1
> SRC=192.168.221.207 DST=192.168.224.2 LEN=48 TOS=0x00 PREC=0x00 TTL=127
> ID=45301 DF PROTO=TCP SPT=3579 DPT=8080 WINDOW=64240 RES=0x00 SYN URGP=0
>
> This is ofcource since I had no Loc->Loc Accept policy.
YES! I was just taking my dog for a walk in the park and thinking about 
your problem and I came to that same conclusion! With the routing that you 
had, the packets being redirected out through the Netgear represented 
loc->loc traffic even if they were redirected using ICMP redirect. I was 
just sitting down to offer you that advice when I saw your post.

 I have _NO_ idea what windows was up to here, but it was no
good.
>
> Tom, what can I say, I am sorry for using Windows to debug :)\
No problem -- I''m just glad that the problem is solved.
>
> Have a nice weekend.
>
Thanks! You too Jan

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net

> YES! I was just taking my dog for a walk in the park and thinking about
> your problem and I came to that same conclusion!
To cold for that here. And it cant exactly be warm there either?
> > Tom, what can I say, I am sorry for using Windows to debug :)\
>
> No problem -- I''m just glad that the problem is solved.
However, if anyone has some advice to WHY Windows 2000 Behaves like this,
feel free to tell me. I think i will try to recreate the problem next week.
I guess i am a born masochist :)
> Thanks! You too Jan
Will be spent on couch :)

--On Friday, January 03, 2003 06:22:02 PM +0100 j2 <spamfilter2@mupp.net> 
wrote:
>
> To cold for that here. And it cant exactly be warm there either?
>
Warm here today -- mid 40''s F. Seattle is roughly the same latitude as 
Bordeaux and has a climate similar to London.

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net

> Warm here today -- mid 40''s F. Seattle is roughly the same
latitude as
> Bordeaux and has a climate similar to London.
Gothenburg sweden. -20C Wanna trade? :) 

Dinnertime!

I know Tom has time off, but I am using his post to illustrate a
weirdness...
>
>Here is what I think you are saying
>
>       Remote system (192.168.224.254)
>        |
>        | (213.212.33.16/255.255.255.240)
>	   |
>       FW---- Netgear (213.212.33.22 proxy-arped)  (FW is
213.212.33.18)
>        |        |
>       Switch ---
>        |
>      local System (192.168.221.202)
Now, if I from .224.254 try "telnet 192.168.202 110" this is what I
can
see in TCP-dump

1 . 16:55:10.025054 192.168.224.254.1110 > pop3.nwl.se.pop3: S
2725679044:2725679044(0) win 5840 <mss 1460,sackOK,timestamp 457699
0,nop,wscale 0> (DF) [tos 0x10]

Ok, so the system starts the session, ok)

2. 16:56:25.922368 192.168.224.254.1112 > hooch.pop3: S
2805775524:2805775524(0) win 5840 <mss 1336,sackOK,timestamp 465297
0,nop,wscale 0> [tos 0x10] 
16:56:25.922399 hooch.pop3 > 192.168.224.254.1112: S
2801776612:2801776612(0) ack 2805775525 win 5792 <mss
1460,sackOK,timestamp 391576591 465297,nop,wscale 0> (DF)
16:56:27.043021 arp who-has 192.168.221.35 tell nwl105.nwl.se
16:56:27.712974 802.1d config 8000.00:30:ab:1b:d2:75.800f root
8000.00:30:ab:1b:d2:75 pathcost 0 age 0 max 20 hello 2 fdelay 15 
16:56:28.910233 192.168.224.254.1112 > hooch.pop3: S
2805775524:2805775524(0) win 5840 <mss 1336,sackOK,timestamp 465597
0,nop,wscale 0> [tos 0x10] 
16:56:28.910252 hooch.pop3 > 192.168.224.254.1112: S
2801776612:2801776612(0) ack 2805775525 win 5792 <mss
1460,sackOK,timestamp 391576889 465297,nop,wscale 0> (DF)

So, .221.202 gets the request and responds.  .221.202 has the following
route

Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
192.168.221.0   *               255.255.255.0   U     0      0        0
eth0
default         argus.nwl.se    0.0.0.0         UG    0      0        0
eth0

3 (this is on FW (192.168.221.7) . 16:57:38.965356
192.168.221.202.pop3
> 192.168.224.254.1113: S 2867649296:2867649296(0) ack 2869588651 win
5792 <mss 1460,sackOK,timestamp 391583748 472454,nop,wscale 0> (DF)
16:57:39.730463 802.1d config 8000.00:30:ab:1b:d2:75.801a root
8000.00:30:ab:1b:d2:75 pathcost 0 age 0 max 20 hello 2 fdelay 15 
16:57:41.309742 arp who-has 192.168.221.35 tell 192.168.221.200
16:57:41.746100 802.1d config 8000.00:30:ab:1b:d2:75.801a root
8000.00:30:ab:1b:d2:75 pathcost 0 age 0 max 20 hello 2 fdelay 15 
16:57:41.949050 192.168.221.202.pop3 > 192.168.224.254.1113: S
2867649296:2867649296(0) ack 2869588651 win 5792 <mss
1460,sackOK,timestamp 391584046 472454,nop,wscale 0> (DF)
16:57:43.199576 192.168.221.202.pop3 > 192.168.224.254.1113: S
2867649296:2867649296(0) ack 2869588651 win 5792 <mss
1460,sackOK,timestamp 391584172 472454,nop,wscale 0> (DF)

It gets the packages and ships them off. The route is

argus:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
smtp.nwl.se     *               255.255.255.255 UH    0      0        0
eth2
213.212.33.22   *               255.255.255.255 UH    0      0        0
eth2
waldorf-ng.mupp *               255.255.255.255 UH    0      0        0
eth2
213.212.33.16   *               255.255.255.240 U     0      0        0
eth0
192.168.224.0   192.168.221.221 255.255.255.0   UG    0      0        0
eth1
192.168.221.0   *               255.255.255.0   U     0      0        0
eth1
192.168.223.0   *               255.255.255.0   U     0      0        0
eth3
192.168.222.0   *               255.255.255.0   U     0      0        0
eth2
default         dslpipe.nwl.se  0.0.0.0         UG    0      0        0
eth0

Now, .221.221 is the VPN router, so I can not tcp dump on it, but, I
will assume that the fw passes the packages to the router. Because If I
ssh directly from the firewall to .224.254 it works.

BUT at the end of the day, .224.254 sees _nothing_ of the return
traffic.. its just dead.

What might be up here?

And if I tell 221.202 "route add -net 192.168.224.0 netmask
255.255.255.0 gw 192.168.221.221" everything works immediately

The firewall has an accept policy to all zones, and I get nothing in the
logs.. 

Whats going on here?

If you want more info on the layout of the network, look at the " VPN
hardware?" thread earlier this week.

Hope I didn''t miss any obvious details.

More details. ICMP works as expected, and when tcpdumping on the FW i see:

argus:~# tcpdump -i eth1 icmp
tcpdump: listening on eth1
23:52:59.973423 192.168.221.202 > 192.168.224.254: icmp: echo reply
23:52:59.980744 192.168.221.202 > 192.168.224.254: icmp: echo reply
23:53:00.962062 192.168.221.202 > 192.168.224.254: icmp: echo reply
23:53:00.969580 192.168.221.202 > 192.168.224.254: icmp: echo reply
23:53:01.961136 192.168.221.202 > 192.168.224.254: icmp: echo reply
23:53:01.969678 192.168.221.202 > 192.168.224.254: icmp: echo reply
23:53:02.961405 192.168.221.202 > 192.168.224.254: icmp: echo reply
23:53:02.971126 192.168.221.202 > 192.168.224.254: icmp: echo reply
23:53:03.961223 192.168.221.202 > 192.168.224.254: icmp: echo reply
23:53:03.972116 192.168.221.202 > 192.168.224.254: icmp: echo reply
23:53:04.074902 192.168.221.7 > 192.168.221.200: icmp: redirect
192.168.224.254 to host 192.168.221.221 [tos 0xc0]

what is this "ICMP redirect" thing? How does it relate? and is it
somehow
related to why "any other" kind of traffic gets lost?

>YES! I was just taking my dog for a walk in the park and thinking about
>your problem and I came to that same conclusion! With the routing that
you 
>had, the packets being redirected out through the Netgear represented 
>loc->loc traffic even if they were redirected using ICMP redirect. I
was 
>just sitting down to offer you that advice when I saw your post.
>No problem -- I''m just glad that the problem is solved.
Well, it wasn''t that simple.. what we have found now is very very
weird.
I have drawn the layout of the network as a jpg, and published it at
http://statler.mupp.net/shorewall/Layout.jpg

Symptoms:
Not able to establish a TCP session over the VPN.
ICMP works fine. 

Test-1:
SSH from 192.168.221.202 -> 192.168.224.254

Result:
SYN/ACK never reaches VPN router (192.168.221.221)
(Last seen in TCP-dump of LOC-interface of FW)

--------------------

Test-2:
SSH from 192.168.224.254 -> 192.168.221.202

Result:
ACK never reaches 192.168.221.221
(last seen in TCP-dump of LOC-interface of FW)

--------------------

Test-3:
Custom generated packages (pacgen 1.01) sent 192.168.221.202 ->
192.168.224.254.
Tcpdump was running on: 192.168.224.254, 192.168.221.7 and on the
Sniffing Brigde. See http://statler.mupp.net/shorewall/Layout.jpg

Result:

RST-packet: Disappears (last seen in TCP-dump of LOC-interface of FW)
ACK-packet: Disappears (last seen in TCP-dump of LOC-interface of FW)
FIN-packet: Disappears (last seen in TCP-dump of LOC-interface of FW)
SYN-packet: OK
URG-packet: OK
PSH-packet: OK

Test-4:
SSH 192.168.221.7 -> 192.168.224.254

Result: OK

-----------------------

Test-5
SSH 192.168.221.202 -> 192.168.224.254 _with_ a direct route 
(route add -net 192.168.224.0 netmask 255.255.255.0 gw 192.168.221.221)

Result: OK

-----------------------

What on earth is eating our packages.

We have the TCPdump results available, but didn''t see the need to
include them.