Having just recently placed a mail server on my DMZ I am now addressing an issue whereby my PPP link (over PPPoE) would drop, then come back up but my routing table would be thereafter mucked up and require manual intervention to reset the networking/shorewall/ipsec utilities to get proper connectivity restored. (Manual intervention was tolerable for my personal use but I need to have my mail server up 7/24).

I am running Bering 1.2. eth0=internet, eth1=private, eth2=DMZ. I am running IPSec.

Relevant package versions are:
Name     Ver          Description
============================================================
initrd   V1.2         LEAF Bering initial filesystem
root     V1.2         Core LEAF Bering package
iptables 1.2.8        IP packet filter admin' tools for 2.4.
ppp      2.4.1-pppoe  Point-to-Point Protocol (PPP) daemon
pppoe    3.3-1        PPPoE add-on for pppd
shorwall 1.4.2        Shoreline Firewall (Shorewall)
ipsec    1.99.6.2     Super Freeswan IPSEC

After a bootup of my LEAF box and all was working well, my routing table would be as follows:
===============================
216.99.105.4 dev ppp0 proto kernel scope link src 216.99.99.35
216.99.105.4 dev ipsec0 proto kernel scope link src 216.99.99.35
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.254
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.1
192.168.1.0/24 via 216.99.105.4 dev ipsec0
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.254
default via 216.99.105.4 dev ppp0


After a PPP link drop (simulated by my powering off my DSL modem) my routing table would be as follows:
===============================
216.99.105.4 dev ipsec0 proto kernel scope link src 216.99.99.35
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.254
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.1
192.168.1.0/24 via 216.99.105.4 dev ipsec0
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.254


After the PPP link restored (simulated by my powering back on, my DSL modem) my routing table would be as follows:
===============================
216.99.105.4 dev ipsec0 proto kernel scope link src 216.99.99.35
216.99.105.4 dev ppp0 proto kernel scope link src 216.99.99.35
10.0.0.0/24 dev eth2 proto kernel scope link src 10.0.0.254
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.1
192.168.1.0/24 via 216.99.105.4 dev ipsec0
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.254
default via 216.99.105.4 dev ipsec0


And thus I don't have connectivity to the internet thereafter. It would appear to me that the 'default' traffic is trying to get out on the ipsec interface which is, as expected, not working.

I resolved this problem by adding to (the bottom of ) the /etc/ppp/ip-down an 'svi ipsec stop' command. To /etc/ppp/ip-up I added 'svi ipsec start'. This has, AFAICT, resolved the issue. Having apparently solved my problem (hacker! :) I'd like to inquire:
- is this the proper way to solve this problem?
- should a change be made to some parts of the IPSec and/or PPP packages to preclude this issue from effecting others?
- and/or should some change to some documentation be made to make mention of this problem and resolution?


I checked the mail archives and relevant documentation (http://leaf.sourceforge.net/doc/guide/buipsec.html) but there was no mention (that I could find) of this problem or resolution.

Thanks for any feedback!

Cheers,
scott; canada



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
------------------------------------------------------------------------
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