Support Requests item #677595, was opened at 2003-01-30 11:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=213751&aid=677595&group_id=13751

Category: packages
Group: None
Status: Open
Priority: 5
Submitted By: Bob Dushok (bdushok)
Assigned to: Mike Noyes (mhnoyes)
Summary: Problems communicating via VPN

Initial Comment:
I'm attempting to configure a subnet to subnet VPN
between two Bering uclibc v1.02 firewalls and am having
difficulty.  The VPN appears to be coming up, but no
traffic seems to pass through it.  My systems are setup
as follows:

workstation1 - ip 10.12.0.2
   |
bering gw - internal 10.12.0.1 - external 66.202.70.89
   |
(internet)
   |
bering gw - internal 10.1.2.200 - external 199.224.108.200
   |
workstation 2 - ip 10.1.1.1

The external IPs are statically assigned, I'm not using
DHCP.

When entering ipsec auto --up vpn I receive the following:

104 "vpn" #8: STATE_MAIN_I1: initiate
106 "vpn" #8: STATE_MAIN_I2: sent MI2, expecting MR2
108 "vpn" #8: STATE_MAIN_I3: sent MI3, expecting MR3
004 "vpn" #8: STATE_MAIN_I4: ISAKMP SA established
112 "vpn" #9: STATE_QUICK_I1: initiate
004 "vpn" #9: STATE_QUICK_I2: sent QI2, IPsec SA
established

The output of ipsec look is:
000 interface ipsec0/eth0 199.224.108.200
000  
000 "vpn":
10.1.0.0/16===199.224.108.200---199.224.108.34...66.202.70.88---66.202.70.89===10.12.0.0/16
000 "vpn":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "vpn":   policy: RSASIG+ENCRYPT+TUNNEL+PFS;
interface: eth0; erouted
000 "vpn":   newest ISAKMP SA: #3; newest IPsec SA: #2;
eroute owner: #2
000  
000 #3: "vpn" STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_REPLACE in 998s; newest ISAKMP
000 #2: "vpn" STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 23043s; newest IPSEC;
eroute owner
000 #2: "vpn" [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]

It appears the VPN is up, but 10.12.0.2 can't ping
10.1.1.1 and vice versa.  My conf looks as follows:
config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=all
        plutoload=%search
        plutostart=%search
        
conn %default
        type=tunnel
        keyexchange=ike
        keylife=8h
        keyingtries=0
        authby=rsasig
        disablearrivalcheck=no  
        pfs=yes

conn vpn
        left=199.224.108.200
        leftsubnet=10.1.0.0/16
        leftnexthop=199.224.108.34
        leftfirewall=yes
        right=66.202.70.89
        rightsubnet=10.12.0.0/16
        rightnexthop=66.202.70.88
        rightfirewall=yes
        auto=add
        leftrsasigkey=(omitted)
        rightrsasigkey=(ommitted)

I've added a zone for the VPN and have a rule similar
to the following added to the Shorewall rules:

vpnnet   localnet    ACCEPT
localnet   vpnnet   ACCEPT

(sorry I don't have the exact text of these rules)

hosts.allow does include an ALL: entry denoting the
private network on the other end of the VPN.

Do I need to perform any masquerading on the IPSEC0
interface for the nets to communicate properly?

As I was searching the mailing list, I noticed
conversations which mentioned an ipsec masquerade
kernel driver.  I can't seem to locate any info on this
for Bering/uclibc.  Am I missing something important? 
The only modules I'm loading for masquerading came with
the Bering release (ip_conntrack_ftp, ip_conntrack_irc,
ip_nat_ftp, and ip_nat_irc).

When shorewall starts it prints a warning indicating
the zone I've created for my VPN is empty.  I've
defined the zone by including the following in the
zones file:

vpnzone  ipsec0

Does this warning indicate a problem?

Any suggestions would be appreciated.
TIA
Bob



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

>Comment By: Lynn Avants (guitarlynn)
Date: 2003-01-30 22:02

Message:
Logged In: YES 
user_id=176069

OK, basic IPSec stuff now.
You can _not_ ping either of the gateways with IPSec with a
tunnel, only machines on the VPN _behind_ the gateways.
Try pinging a client on one subnet from a client on the other
subnet. To ping either gateway, another link must be brought
up that is a host connection as opposed to a gw-tunnel.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=213751&aid=677595&group_id=13751


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
------------------------------------------------------------------------
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

Reply via email to