Ok, my fears were correct :( I have a problem with a race condition the involves IPSec and Shorewall with Bering 1rc3... Here's the bad ASCII art again:
10.0.0.0/24 firewall 192.168.0.0/24
| |
firewall - Internet
| |
10.0.1.0/24 firewall 192.168.1.0/24
10.0.1.0/24 can see 10.0.0.0/24, but 10.0.0.0/24 isn't allowed in
10.0.1.0/24.. That works great.. 192.168.0.0/24 needs to get into
10.0.0.0/24, and 192.168.01./24 needs into 10.0.1.0/24.. Now, when I set
this up in Shorewall, I define as follows:
Interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
#
net eth0 detect dhcp,norfc1918
loc eth1 detect routestopped
dmz eth2 detect routestopped,dhcp
gw0 ipsec0
gw1 ipsec1
Rules:
#SOURCE DEST POLICY LOG LEVEL
#LIMIT:BURST
loc net ACCEPT
dmz net ACCEPT
dmz loc ACCEPT
loc:10.0.0.201 dmz ACCEPT
# FreeSwan
dmz gw1 ACCEPT
gw1 dmz ACCEPT
loc gw0 ACCEPT
gw0 loc ACCEPT
So, the problem is, whoever gets in first gets ipsec0, which is gw0,
which may or may not be the right one. Any ideas on how to prevent this
from happening?
On another note, both of these are mapping drives in Windows across these
links. One is from 2000 Pro to 98, works fine. The other is from XP Home
to 2000 Server with Active Directory.. The maps here work fine, except for
two. They are limmitted access, where the others are open. These maps work
fine from local with the user/login I setup for the remote, but will not
map accross the VPN. I have other XP Home systems logging in just fine
locally, it's just this one from remote. I even turned on the allow from
VPN, thinking that might help, with it being a different IP block.. Any
tips, pointers to RTFM's appreciated.. I searched the knowledgebase at
Microsoft, but didn't find anything there...
---
Homer Parker
http://www.homershut.net
telnet://bbs.homershut.net
msg11360/pgp00000.pgp
Description: PGP signature
