Tunneling problem

Tunneling problem

Post by HERRMANN Luci » Tue, 26 Mar 1996 04:00:00



Hello

I'm trying to use the tun0 interface on the NetBSD station 130.79.8.132.
I configure it with the ifconfig command :
# ifconfig tun0 130.79.8.132 130.79.200.47 netmask 255.255.255.0

Here are all the different interface (we're using IPv6 adresses too but
not for the tun0 interface) :

le0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 130.79.8.132 netmask 0xffffff00 broadcast 130.79.8.255
        inet6 5f08:d300:824f::800:2003:377d/80
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 32768
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1/128
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
ppp0: flags=10<POINTOPOINT> mtu 1500
ppp1: flags=10<POINTOPOINT> mtu 1500
tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500
        inet 130.79.8.132 --> 130.79.200.47 netmask 0xffffff00
tun1: flags=10<POINTOPOINT> mtu 1500
tun2: flags=10<POINTOPOINT> mtu 1500
tun3: flags=10<POINTOPOINT> mtu 1500
sit0: flags=11<UP,POINTOPOINT> mtu 1480
        inet 130.79.8.132 --> 0.0.0.0 netmask 0xffff0000
        inet6 ::824f:884/96 --> ::

The routing tables are changed automaticaly by the ifconfig command :

Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
127.0.0.1          127.0.0.1          UH          1       24      -  lo0
130.79.8/24        link#1             UC          0        0      -  le0
130.79.8.132       8:0:20:3:37:7d     UHL         0        0      -  lo0
130.79.200/24      130.79.8.254       UG          0        0      -  le0
130.79.200.47      130.79.8.132       UH          0        0      -  tun0

IPv6:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
::/96              0.0.0.0            UCS         0        0      -  sit0 =>
default            fe80::800:2003:377d US          0        0   1500  le0
::1                ::1                UH          0        0      -  lo0
::7f00:1           ::7f00:1           UH          0        0      -  lo0
::824f:0/112       link#1             UC          0        0   1500  le0
5f08:d300:824f::/80 link#1             UC          0        0   1500  le0
fe80::/80          link#1             UC          0        0   1500  le0
ff01::/16          ::1                US          0        0      -  lo0
ff02::/16          fe80::800:2003:377d US          0        0   1500  le0
ff11::/16          ::1                US          0        0      -  lo0
ff12::/16          fe80::800:2003:377d US          0        0   1500  le0

Now i'm trying to access the 130.79.200.47 station :
#ping 130.79.200.47
ping: sendto: Host is down....

I'm looking with a network packets analyser and nothing goes out of the
station. I think that i have to link the tun0 interface with le0, but I
don't know how to do it.

Thank you for your help.

-----------------------------------------
Lucien Herrmann
Universite Louis Pasteur

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

 
 
 

Tunneling problem

Post by Christoph Badu » Wed, 27 Mar 1996 04:00:00



Quote:>I'm trying to use the tun0 interface on the NetBSD station 130.79.8.132.

Do you have a user process reading the packets off of /dev/tun0?

--

You don't need to quote my .signature.  Everyone has seen it by now.
Besides, it doesn't add anything to the current thread.

 
 
 

Tunneling problem

Post by Brian Some » Tue, 02 Apr 1996 04:00:00


: Hello

: I'm trying to use the tun0 interface on the NetBSD station 130.79.8.132.
: I configure it with the ifconfig command :
: # ifconfig tun0 130.79.8.132 130.79.200.47 netmask 255.255.255.0

: Here are all the different interface (we're using IPv6 adresses too but
: not for the tun0 interface) :

[ rest deleted ]

On a side-line, can anyone point to any docs on IPv6 ?  Is there an RFC ?

Thanks.

--

Don't _EVER_ lose your sense of humour....

 
 
 

1. microsoft ipsec problem with linux iptables nat tunnel: problem in isakmp key exchange apparently

Hi,

For the last weeks, i've been debugging a problem with the following setup:

windows 2000 laptop - NAT'ing linux iptables firewall - windows 2000 vpn
server

the vpn solution is standard microsoft ipsec, ESP in tunnel mode
keys are public/private keys based on our company's active directory
(whatever that means).

the many (sometimes) conflicting documents i read about this suggest that it
is possible, under certain circumstances:

- if AH (authentication header) protocol is used, just forget about , not
possible with NAT (not in my case fortunately)
- if ESP is used, it depends if tunnel or transport mode is used.
    for tunnel mode, it should work if client and server agree to do udp
encapsulation (I suppose that they mean that the client and server are NAT-T
compatible).

Our network guys have confirmed me that their solution is indeed NAT-T
compatible

when i try to start a vpn connection while my laptop is behind the nat'ing
firewall, i made the following observations with a network sniffer:

i tried to verify the packet exchange between 2 situations:

1) directly connected, no firewall in between (it works this way)
2)  behind the firewall (does not work).

I noticed (thank you ethereal network sniffer) this:

the first packets that are exchanged seem similar in both cases:

5 packets between client and server, from udp 500 to udp 500
after that 2 fragmented udp packets (i can't see more details about it, not
in ethereal, nor with tcpdump)
then in the 8th packet i see a difference:
this is an isakmp packet (udp 500 to udp 500),

but when the laptop is connected directly, i see in the isakmp part of the
packet,
next payload: key exchange (4), flags: no encryption, no commit, no
authentication

and in the other case (behind firewall),:

next payload: identification (5), encryption, no commit, no authentication

the packet in the ok situation has some other headers like key exchange
payload, nonce payload, certificate request payload, while in the bad packet
, i see none of thease headers (just: encrypted payload: 4432 bytes).

It's as if at that time, the key exhcange is stopped because the NAT'ing
interfered somehow ???

Just for the record, there are NO dropped packets because of firewall
limitations, at least not as far as i could tell.

Any ideas what to do next ?

I'm almost ready to throw in the towel, cause i'm getting buried deep in the
nitty gritty of the ipsec protocol, just thought i'd ask the all-knowing
usenet audience for some ultimate guidance :)

thank you,

Tom.

2. su: user root does not exist

3. reverse SSH tunnel problem

4. trap "<new trap action>; $(get_old_trap SIGNAL)" SIGNAL

5. xemacs through ssh-tunnel problem

6. Setting up Intel EtherExpress 16....

7. IP-tunneling problem

8. Strange problem with LILO

9. Help ! Tunnel problem

10. IPv6/IPv4 tunnel problems

11. IP in IP tunnel problem

12. IP tunneling problem

13. IPIP Tunnelling problem