OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Wolfgang Schulz (Home) (w.schulz_at_ove.at)
Date: Sun Aug 11 2002 - 15:54:45 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    > -----Ursprüngliche Nachricht-----
    > Von: Steffen Dettmer [mailto:steffendett.de]
    > > I'm using SuSE 7.0 (with FreeS/WAN 1.4) on a firewall gateway
    > > and SafeNet/Softremote for a WIN2000 machine and want to
    > > configure a road warrior VPN. The road warriod should connect
    > > to a maskeraded net (10.96.1.64/26) behind the firewall. The
    > > problem which makes me cracy is the following: I can establish
    > > an SA - there is a tunnel between the WIN2000 machine and the
    > > firewall. I can ping from the road warrior PC to the internal
    > > address of the firewall (10.96.1.102) but I can't ping or make
    > > a connection to any other machine in that subnet.
    >
    > May it be a "ordinary" routing problem? From the firewall / VPN
    > GW, you can ping -I 10.96.1.102 10.96.1.65 (or whatever
    > destination)?

    I can only ping the internal interface of the firewall (10.96.1.102) but no
    other address of this subnet. But also with 10.96.1.102 there is something
    not correct because I can't establish a tcp connection e.g. to port 22
    (where sshd is listening).

    > > I tested with tcpdump that the ICMP packets arrive at the ipsec
    > > interfac on the firewall but nothing is sent out at the
    > > internal interface (eth0).
    >
    > Do you use rp filters? Do you have ip forward enabled? Strange...
    > You tried it without firewalling at all, correct?

    I tried it without firewall rules. IP forward is enabled.

    > > For me this looks like a routing problem but I have no idea
    > > what could be configured in another way.
    >
    > Is this configured on the same VPN GW / external box? Is the
    > setup the same but without a road warrior?

    It is my intention to configure the other VPN connection on the same box but
    it is not done at the moment. I only wanted to emphasize with this statement
    that the firewall rules should be ok. Also there are no rejected packets in
    the log.

    Without established connection I have:
    fw:~ # netstat -rn
    Kernel IP routing table
    Destination Gateway Genmask Flags MSS Window irtt
    Iface
    213.30.70.232 0.0.0.0 255.255.255.248 U 0 0 0
    eth1
    213.30.70.232 0.0.0.0 255.255.255.248 U 0 0 0
    ipsec0
    10.96.1.64 0.0.0.0 255.255.255.192 U 0 0 0
    eth0
    10.96.1.128 10.96.1.106 255.255.255.192 UG 0 0 0
    eth0
    127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
    0.0.0.0 213.30.70.233 0.0.0.0 UG 0 0 0
    eth1

    With established connection I get (I hope I have the first line correctly in
    my mind because I can't currently establisg a connection becasue I'm at
    home):
    fw:~ # netstat -rn
    Kernel IP routing table
    Destination Gateway Genmask Flags MSS Window irtt
    Iface
    xxx.xxx.xxx.xxx 213.30.70.233 255.255.255.0 U 0 0 0
    ipsec0
    213.30.70.232 0.0.0.0 255.255.255.248 U 0 0 0
    eth1
    213.30.70.232 0.0.0.0 255.255.255.248 U 0 0 0
    ipsec0
    10.96.1.64 0.0.0.0 255.255.255.192 U 0 0 0
    eth0
    10.96.1.128 10.96.1.106 255.255.255.192 UG 0 0 0
    eth0
    127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
    0.0.0.0 213.30.70.233 0.0.0.0 UG 0 0 0
    eth1

    I searched in a lot of archives today and found a lot of questions where the
    problems sound similar to me, but I found no solution or answer to the
    problem.

    As I stated in my first email: If I start a ping from an internal machine
    (e.g. 10.96.1.116) I see with tcpdump at the ipsec0 interface that there is
    an ICMP packet sent out and there is also an answer arriving. But this
    answer is not forwarded to the internal interface (eth0).

    I really don't know anymore what to do!

    Wolfgang

    > oki,
    >
    > Steffen
    >
    > --
    > Dieses Schreiben wurde maschinell erstellt,
    > es trägt daher weder Unterschrift noch Siegel.
    >
    > --
    > To unsubscribe, e-mail: suse-security-unsubscribesuse.com
    > For additional commands, e-mail: suse-security-helpsuse.com
    > Security-related bug reports go to securitysuse.de, not here
    >

    -- 
    To unsubscribe, e-mail: suse-security-unsubscribesuse.com
    For additional commands, e-mail: suse-security-helpsuse.com
    Security-related bug reports go to securitysuse.de, not here