Re: ipsec vpn session end causes pppoe to die...

This is a discussion on Re: ipsec vpn session end causes pppoe to die... within the Linux Networking forums, part of the Linux Forums category; James Carlson <james.d.carlson@sun.com> wrote in message news:<xoavr85lxbbc.fsf@sun.com>... > ...


Go Back   Usenet Forums > Linux Forums > Linux Networking

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 06-24-2003
James
 
Posts: n/a
Default Re: ipsec vpn session end causes pppoe to die...

James Carlson <james.d.carlson@sun.com> wrote in message news:<xoavr85lxbbc.fsf@sun.com>...
> rolyat_n_semaj@yahoo.co.uk (James) writes:
> > Sorry, I though it was fairly clear. Normal senario: Company x has

>
> It must not have been, at least to me ... that description looks quite
> different from what appeared before.
>
> > adsl connection to internet using IPCop as firewall/gateway - all

> [...]
> > this is the issue: When the Win2K IPsec client manually disconnects
> > VPN connection to IPSec firewall, IPSec firewall closes connection,
> > then completly drops it's whole connection to the internet, so the
> > whole office loses it's connection and one has to go through multiple
> > restarts (of adsl modem/ppp link) before bringing back access.

>
> It sounds like "IPsec firewall" is misconfigured to think that "Win2K
> IPsec client" is the sole gateway to the Internet. At a *really* wild
> guess (since I *still* can't see those configuration files), I'd
> expect that there's a misplaced "defaultrouter" in one of the pppd
> configuration files, and that's destroying the default route to the
> Internet.


There is a bug for the IPcop firewall (the linux firewall/gateway)
that says that IPCop loses it's default route to ppp when
disconnecting. I should point out that this firewall connects to a
static ADSL connection. "Default route points via IPSEC after
reconnect When an IPCop box loses it's ppp connection (eg when using a
Pulsar ADSL card and the link sync is lost), IPSec is not unloaded by
ip-down. When the ADSL link is re- established and the connection is
back up, instead of the default route being via ppp0, it is via
ipsec0. "
http://sourceforge.net/tracker/index...04&atid=428516

However I have implemented this and the problem still occurs.

What config files would you like? I should remind you that i'm fairly
new to linux and don't know where all the configuration files are
installed. But are these ok?

***********
netstat- nr

netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window
irtt Iface
x.x.x.1 0.0.0.0 255.255.255.255 UH 40 0
0 ppp0
x.x.x.1 0.0.0.0 255.255.255.255 UH 40 0
0 ipsec0
192.168.2.0 0.0.0.0 255.255.255.0 U 40 0
0 eth2
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0
0 eth0
1.1.1.0 0.0.0.0 255.255.255.0 U 40 0
0 eth1
0.0.0.0 x.x.x.1 0.0.0.0 UG 40 0
0 ppp0

*************
ipsec.conf:

config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes

conn %default
keyingtries=0

conn Opipo_office
left=x.x.x.x # [static]
compress=no
leftsubnet=192.168.1.0/24
leftnexthop=%defaultroute
type=tunnel
authby=secret
pfs=yes
right=%any
rightsubnet=
rightnexthop=%defaultroute
auto=add
***************

ip_down:

#!/usr/bin/perl
#
# SmoothWall CGIs
#
# This code is distributed under the terms of the GPL
#
# (c) The SmoothWall Team
#
# $Id: ip-down,v 1.2.2.9 2003/01/13 09:16:03 riddles Exp $
#

require '/var/ipcop/header.pl';

&log("PPP has gone down on $ARGV[0]");

umask 022;

my %pppsettings;
my %dhcpsettings;

# read vars back from file.
&readhash("${swroot}/ppp/settings", \%pppsettings);
&readhash("${swroot}/dhcp/settings", \%dhcpsettings);

unlink "${swroot}/red/active";
system "/etc/rc.d/rc.updatered";

system "/bin/echo -en \a >/dev/console";
sleep 1;
system "/bin/echo -en \a >/dev/console";

******************

ip_up:

#!/usr/bin/perl
#
# SmoothWall CGIs
#
# This code is distributed under the terms of the GPL
#
# (c) The SmoothWall Team
#
# $Id: ip-up,v 1.2.2.14 2003/02/06 15:52:46 riddles Exp $
#

require '/var/ipcop/header.pl';

&log("PPP has gone up on $ARGV[0]");
umask 022;

my %pppsettings;
my %dhcpsettings;

# read vars back from file.
&readhash("${swroot}/ppp/settings", \%pppsettings);
&readhash("${swroot}/dhcp/settings", \%dhcpsettings);

if ( ( $pppsettings{'TYPE'} eq 'isdn') &&
( $pppsettings{'COMPORT'} eq 'isdn2') &&
( $pppsettings{'USEIBOD'} eq 'off') ) {
system('/usr/sbin/isdnctrl', 'dial', 'ippp1');
}

my $dns = $pppsettings{'DNS'};
my $primarydns = $pppsettings{'DNS1'};
my $secondarydns = $pppsettings{'DNS2'};
if ($dns eq 'Automatic') {
if (!($pppsettings{'TYPE'} =~ /^isdn/))
{
if (open(FILE, ">${swroot}/red/dns1")) { print FILE $ENV{'DNS1'};
close FILE; }
if (open(FILE, ">${swroot}/red/dns2")) { print FILE $ENV{'DNS2'};
close FILE; }
}
else
{
if (open(FILE, ">${swroot}/red/dns1")) { print FILE $ENV{'MS_DNS1'};
close FILE; }
if (open(FILE, ">${swroot}/red/dns2")) { print FILE $ENV{'MS_DNS2'};
close FILE; }
}
} else {
if (open(FILE, ">${swroot}/red/dns1")) { print FILE
$pppsettings{'DNS1'}; close FILE; }
if (open(FILE, ">${swroot}/red/dns2")) { print FILE
$pppsettings{'DNS2'}; close FILE; }
}

if (open(FILE, ">${swroot}/red/iface")) { print FILE $ARGV[0]; close
(FILE); }
if (open(FILE, ">${swroot}/red/local-ipaddress")) { print FILE
$ARGV[3]; close (FILE); }
if (open(FILE, ">${swroot}/red/remote-ipaddress")) { print FILE
$ARGV[4]; close (FILE); }

system('/bin/touch', "${swroot}/red/active");
system('/etc/rc.d/rc.updatered');

system "/bin/echo -en '\a' >/dev/console";

****************

rc.updater

#!/bin/sh

.. /var/ipcop/dhcp/settings
.. /var/ipcop/ethernet/settings
.. /var/ipcop/ppp/settings

IFACE=`/bin/cat /var/ipcop/red/iface 2>/dev/null | /usr/bin/tr -d
'\012'`
OLDIP=`/bin/cat /var/ipcop/red/local-ipaddress 2>/dev/null |
/usr/bin/tr -d '\012'`

###
### Retrieve DHCP Settings
###
if [ "$CONFIG_TYPE" = "2" -o "$CONFIG_TYPE" = "3" ]; then
if [ "$RED_TYPE" = "DHCP" ]; then
unset DNS1 DNS2
. /var/ipcop/ethernet/settings
if [ "$DNS1" = "" ]; then
echo -n `/etc/rc.d/helper/getdnsfromdhcpc.pl 1` >
/var/ipcop/red/dns1
echo -n `/etc/rc.d/helper/getdnsfromdhcpc.pl 2` >
/var/ipcop/red/dns2
else
echo "$DNS1" > /var/ipcop/red/dns1
echo "$DNS2" > /var/ipcop/red/dns2
fi
. /etc/dhcpc/dhcpcd-${RED_DEV}.info
echo "$IPADDR" > /var/ipcop/red/local-ipaddress
echo "$GATEWAY" > /var/ipcop/red/remote-ipaddress
fi
else
if [ "$PROTOCOL" = "RFC1483" -a "$METHOD" = "DHCP" ]; then
unset DNS1 DNS2
. /var/ipcop/ppp/settings
if [ "$DNS" = "Automatic" ]; then
echo -n `/etc/rc.d/helper/getdnsfromdhcpc.pl 1` >
/var/ipcop/red/dns1
echo -n `/etc/rc.d/helper/getdnsfromdhcpc.pl 2` >
/var/ipcop/red/dns2
else
echo "$DNS1" > /var/ipcop/red/dns1
echo "$DNS2" > /var/ipcop/red/dns2
fi
. /etc/dhcpc/dhcpcd-${IFACE}.info
echo $IPADDR > /var/ipcop/red/local-ipaddress
echo $GATEWAY > /var/ipcop/red/remote-ipaddress
fi
fi

###
### Retrieve DNS settings
###
DNS1=`/bin/cat /var/ipcop/red/dns1 | /usr/bin/tr -d '\012'`
DNS2=`/bin/cat /var/ipcop/red/dns2 | /usr/bin/tr -d '\012'`
if [ "$DNS1" != "" ]; then
if [ "$DNS2" != "" ]; then
echo "nameserver $DNS1" > /var/ipcop/red/resolv.conf
echo "nameserver $DNS2" >> /var/ipcop/red/resolv.conf
else
echo "nameserver $DNS1" > /var/ipcop/red/resolv.conf
fi
else
echo > /var/ipcop/red/resolv.conf
fi

###
### Restart DNSMASQ
###
/usr/bin/killall dnsmasq
if [ -e "/var/ipcop/red/dial-on-demand" -a "$DIALONDEMANDDNS" == "on"
-a ! -e "/var/ipcop/red/active" ]; then
if [ "$DOMAIN_NAME" == "" ]; then
/usr/local/bin/dnsmasq -l /var/lib/dhcp/dhcpd.leases \
-r /var/ipcop/ppp/fake-resolv.conf
else
/usr/local/bin/dnsmasq -l /var/lib/dhcp/dhcpd.leases \
-s "$DOMAIN_NAME" -r /var/ipcop/ppp/fake-resolv.conf
fi
else
if [ "$DOMAIN_NAME" == "" ]; then
/usr/local/bin/dnsmasq -l /var/lib/dhcp/dhcpd.leases \
-r /var/ipcop/red/resolv.conf
else
/usr/local/bin/dnsmasq -l /var/lib/dhcp/dhcpd.leases \
-s "$DOMAIN_NAME" -r /var/ipcop/red/resolv.conf
fi
fi

# Reset default route to ippp0 for dial on demand
if [ -e "/var/ipcop/red/dial-on-demand" -a "$TYPE" == "isdn" -a ! -e
"/var/ipcop/red/active" ]; then
/sbin/route add default dev ippp0
fi

if ( echo $0 | /bin/grep -q dhcp ); then
. /etc/dhcpc/dhcpcd-${IFACE}.info
if [ "$OLDIP" != "$IPADDR" ]; then
/usr/local/bin/setddns.pl
unset ENABLED
. /var/ipcop/vpn/settings
if [ "$ENABLED" == "on" ]; then
/etc/rc.d/ipsec restart
fi
fi
else
if [ -e "/var/ipcop/red/active" ]; then
[ "$IFACE" != "" ] && /sbin/ifconfig $IFACE -multicast
/etc/rc.d/rc.firewall reload
/usr/local/bin/updatelists.pl &
/usr/local/bin/restartsnort
/usr/local/bin/setportfw
/usr/local/bin/setxtaccess
/usr/local/bin/setddns.pl
/etc/rc.d/helper/writeipac.pl
/etc/rc.d/helper/writemrtg.pl
/usr/local/sbin/fetchipac -S
unset ENABLED
. /var/ipcop/vpn/settings
if [ "$ENABLED" == "on" ]; then
/etc/rc.d/ipsec restart
fi
else
if [ "$ENABLED" == "on" ]; then
/etc/rc.d/ipsec stop
fi
/etc/rc.d/rc.firewall reload
fi
fi

**********************

> Dial-in links generally should not have "defaultrouter" anywhere in
> the configuration, including /etc/ppp/options.


Output of /etc/ppp/options:

linkname ipcop
noauth

>
> Still missing configuration information for those components ...
>
> > > Some hints about your configuration might help as well. It's hard to
> > > guess at the contents of your configuration files.

> >
> > Config: One Linux firewall with 3 NICS, not worried about 2 internal
> > nics. 1 NIC connected to (red) ADSL Dlink dsl-300 in bridge mode,
> > i.e. Linux controls the connection, not the modem to ti ISP. IPCop
> > includes - FreeSwan as vpn server.

>
> None of the above looks like a configuration file.


How about this:

*****************
/var/ipcop/ppp/settings

DIALMODE=
DNS=Manual
CONCENTRATORNAME=
IP=
COMPORT=
PROFILENAME=xxxxxxxx
USERNAME=xxxxxxxx@xxxxxxxxxxx.com.au
LOGINSCRIPT=
DTERATE=
VALID=yes
USEIBOD=off
AUTH=pap-or-chap
PROTOCOL=
TELEPHONE=
MAXRETRIES=25
DIALONDEMAND=off
PROFILE=1
DIALONDEMANDDNS=off
TYPE=pppoe
SPEAKER=off
VPI=
SERVICENAME=
TIMEOUT=0
SENDCR=off
ENCAP=
VCI=
DNS1=x.x.x.x
AUTOCONNECT=on
PHONEBOOK=
DNS2=x.x.x.x
ROUTERIP=
PASSWORD=xxxxxxxx
PERSISTENT=on
USEDOV=off
METHOD=
******************

>
> > > > 18:17:34 pppoe Timeout waiting for PADO packets
> > >
> > > That's another PPPoE problem. In this case, timing out waiting for
> > > PADO means that the PPPoE peer doesn't exist, or is ignoring you, or
> > > the Ethernet cable is broken.

> >
> > Part of the disconnection problem above

>
> If that's really part of the disconnection problem, then there are
> bigger problems here. You'll need to debug the machine at the other
> end of this connection to find out why it's not bothering to respond
> to PADO.


So vpn link disconnected...
Then this happens...

14:06:57 pppd No response to 3 echo-requests
14:06:57 pppd Serial link appears to be disconnected.
14:07:03 pppd Connection terminated.
14:07:03 pppd Connect time 1055.4 minutes.
14:07:03 pppd Sent 12194796 bytes, received 32547418 bytes.
14:07:03 pppd Using interface ppp0
14:07:03 pppd Connect: ppp0 <--> /dev/ttyp1
14:07:03 pppoe read (asyncReadFromPPP): Input/output error
14:07:03 pppoe Sent PADT
14:07:38 pppoe Timeout waiting for PADO packets
14:07:38 pppd Modem hangup
14:07:38 pppd Connection terminated.
14:07:38 pppd Using interface ppp0
14:07:38 pppd Connect: ppp0 <--> /dev/ttyp0
14:08:24 pppoe Timeout waiting for PADO packets
14:08:24 pppd Modem hangup
14:08:24 pppd Connection terminated.
14:08:24 pppd Using interface ppp0
14:08:24 pppd Connect: ppp0 <--> /dev/ttyp0
14:08:24 pppoe PPP session is 2113
14:08:26 pppd local IP address x.x.x.x
14:08:26 pppd remote IP address x.x.xx.


>
> > > > 18:19:19 pppoe PPP session is 2035
> > > > 2. Disconnect PPP on firewall GUI or 'rc.red stop'
> > >
> > > Perhaps the problem is in your tear-down script.

> >
> > I'm afraid I didn't write it and am relatively new to Linux. This is
> > what should happen - the VPN client should informe the VPN server that
> > it is closing the connection, the VPN server should close the IPSec
> > tunnel (running through ppp) and wait for the next client to connect.
> > All through this the ppp connection should stay available.

>
> It looks like the script doesn't do that at all. It looks to me like
> it shuts down PPP.
>
> > > > Could it be mtu? Or what about tx/rx buffers? A duff adsl modem?
> > >
> > > Sorry ... none of those explanations appear to be related to the
> > > problem.

> >
> > My thoughts being, as I read on the Internet somewhere, that bad MTU
> > sizes can cause VPN tunnels big issues although I can't make the

>
> Bad MTU sizes cause predictable sorts of problems: certain sites
> (those with broken PMTUD, specifically) will be unreachable. Access
> to some others will work but perform badly.
>
> They don't just cause PPP connections to drop or fail to start.
>
> > connection - perhaps it might be related to the i) modem or ii) Linux
> > gateways difficulty when receiving the vpn tunnel close signal. Some
> > people reccomend 1400 for PPTP VPN tunnel, 1492 for pppoe, but better
> > 1454 for optimal over atm. some say set really small mtu for vpn e.g.
> > 576. I don't know the reccommended size for IPSec.

>
> IPsec doesn't have a recommended MTU.
>
> For PPPoE, you're restricted to a maximum MTU/MRU of 1492 -- this is
> because the protocol adds 8 octets of overhead to each packet, and the
> maximum Ethernet frame size is 1500 octets.
>
> The ATM default MTU/MRU (at least for RFC 2225 CLIP) is 9180 octets.
> I have no idea where 1454 as "optimal" for ATM might be specified.


http://www.mynetwatchman.com/kb/adsl/pppoemtu.htm

>
> As for PPTP, that's essentially a proprietary protocol. You'll need
> to contact Microsoft.


Not interested in PPTP - but this faq indicates a max MTU of 1400 for
WinXP
http://www.dslreports.com/faq/4613

>
> > Would you suspect the modem ('s inability to handle the session as
> > indicated by fist ppp error message)or the linux ('s inability to
> > close the ipsec session without killing all sessions) box?

>
> Assuming that the Linux box is the one that is acting as "IPCop as
> firewall/gateway" (it's still not clear to me from the text provided),
> yes, I'd suspect that the Linux box is misconfigured. It sounds as
> though it's ripping up its default route.


Yes it is Linux box = IPCop firewall/gateway. IPCop - www.ipcop.org. A
application pulling together iptables, squid, dhcp, freeswan and snort
(IDS).

>
> That's just a wild guess. You'll need to look at configuration files,
> debug logs ("man syslog" might be a start), and the output from
> "netstat -nr" (or "route -n" on Linux) on multiple machines to come up
> with a cause for the problem. If I were you, I'd start with the
> machine that appears to be the proximate cause of the problem -- that
> "IPCop as firewall/gateway" box, and its state before and after all
> connectivity is lost.


Thanks James
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 09:24 AM.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0