[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: topology does work on mac osx with a manual work arround (wasRe: [Openvpn-users] topology subnet 2.1beta7 mac osx - ifconfig: ioctl (SIOCAIFADDR): Destination address required


  • Subject: Re: topology does work on mac osx with a manual work arround (wasRe: [Openvpn-users] topology subnet 2.1beta7 mac osx - ifconfig: ioctl (SIOCAIFADDR): Destination address required
  • From: Mathias Sundman <mathias@xxxxxxxxxx>
  • Date: Fri, 2 Dec 2005 12:17:56 +0100 (CET)

On Thu, 1 Dec 2005, Jon Bendtsen wrote:

Den 1. dec 2005 kl. 14:54 skrev Mathias Sundman:

No, I don't think we should universally push a route, since that will break platforms which don't need the extra route in the first place (like Linux or Windows).

I think it would be better if the OpenVPN client generates the "route add" by itself, on platforms where the tun/tap driver can't accept a netmask in tun mode.

Okay, attached is a new patch that adds this route automatically. Could you please try it Jon.

It does sort of work.

However, if i ping a unused IP address i get this:
tcpdump: 16:00:39.564517 IP 192.168.123.34 > 192.168.123.36: icmp 92: redirect 192.168.123.39 to host 192.168.123.39
PING 192.168.123.39 (192.168.123.39): 56 data bytes
92 bytes from 192.168.123.34: Redirect Host(New addr: 192.168.123.39)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 f4ae 0 0000 3f 01 0f5e 192.168.123.36 192.168.123.39


and if i ping my own address i get the same error:
tun0: flags=8951<UP,POINTOPOINT,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
      inet 192.168.123.36 --> 192.168.123.36 netmask 0xffffff00
      open (pid 2103)
PING 192.168.123.36 (192.168.123.36): 56 data bytes
92 bytes from 192.168.123.34: Redirect Host(New addr: 192.168.123.36)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 f4fb   0 0000  3f  01 0f14 192.168.123.36  192.168.123.36

64 bytes from 192.168.123.36: icmp_seq=0 ttl=63 time=11.515 ms
92 bytes from 192.168.123.34: Redirect Host(New addr: 192.168.123.36)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 f50c   0 0000  3f  01 0f03 192.168.123.36  192.168.123.36

64 bytes from 192.168.123.36: icmp_seq=1 ttl=63 time=3.442 ms

16:06:09.918826 IP 192.168.123.34 > 192.168.123.36: icmp 92: redirect 192.168.123.36 to host 192.168.123.36
16:06:09.919055 IP 192.168.123.36 > 192.168.123.36: icmp 64: echo request seq 1
16:06:09.919130 IP 192.168.123.36 > 192.168.123.36: icmp 64: echo reply seq 1
16:06:09.920567 IP 192.168.123.36 > 192.168.123.36: icmp 64: echo reply seq 1


16:06:15.151314 IP 192.168.123.36 > 192.168.123.36: icmp 64: echo request seq 2
16:06:15.152495 IP 192.168.123.34 > 192.168.123.36: icmp 92: redirect 192.168.123.36 to host 192.168.123.36
16:06:15.152714 IP 192.168.123.36 > 192.168.123.36: icmp 64: echo request seq 2
16:06:15.152789 IP 192.168.123.36 > 192.168.123.36: icmp 64: echo reply seq 2
16:06:15.154256 IP 192.168.123.36 > 192.168.123.36: icmp 64: echo reply seq 2

I honestly don´t know how tun interfaces "subnet mode" are expected to behave. I cannot think of any other way to configure the interface and routes either to avoid this behavior.


Does your linux client behave diffrently?

I assume you got the same bahvior when manually configuring the interface and routes, so my patch havn´t changed anything, right?

--
_____________________________________________________________
Mathias Sundman                  (^)   ASCII Ribbon Campaign
OpenVPN GUI for Windows           X    NO HTML/RTF in e-mail
http://openvpn.se/               / \   NO Word docs in e-mail