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

[James Yonan <jim@xxxxxxxxx>]

On Fri, 2 Dec 2005, Mathias Sundman wrote:

> On Thu, 1 Dec 2005, Jon Bendtsen wrote:
> 
> > 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)
> 
> I couldnīt stop thinking about this... I must admit I lack some knowledge 
> about tun interface, but I'll make an attempt here to try descibe what I 
> think is happening. Please correct my faults and fill in the gaps.
> 
> When you, the OpenVPN client sends a ping to an unused IP in the subnet 
> assigned to your tun interface, this will, according to your route, be 
> sent out on your tun interface.
> 
> This will be recieved by the OpenVPN server which sees a ping packet with 
> a dest IP that is unknown for OpenVPN. So what happends then? Itīs no 
> ethernet interface so we canīt broadcast any arp request. So, as I see it 
> we can do 3 things.
> 
> 1) Drop the packet.
> 2) Send it down to the kernel on the server via the tun interface.
> 3) Broadcast the packet to all clients (including the server itself).
> 
> My guess is that 2 (or maybe 3) is what happends.

Actually 2 occurs right now.  If the OpenVPN server gets a packet from a 
client, it forwards it to the local tun interface (unless 
--client-to-client is set and the address is an address which explicitly 
belongs to another client, in which case it is forwarded that client).

Arguably, OpenVPN could do (1) since it knows that it "owns" the subnet, 
therefore forwarding to the kernel via the tun interface is not likely to 
produce a useful result.  The kernel is just going to throw up its hands 
and say "why do I need to be involved in this transaction between two 
hosts on the same ethernet subnet where neither of the hosts involved is 
me".

Of course, the ICMP redirect generated by kernel is the appropriate
response to this.  The kernel examines the IP header, sees that the sender
and receiver are on the same subnet, and produces the redirect to the tell
the sender that it can reach the destination directly.  Of course in
reality, the subnet is virtual, but the kernel can't know that.

> Anyway, now the kernel on the OpenVPN server sees a packet comming in the 
> tun interface destinated for an IP that is not itīs own, so it wonders, 
> why did this come here in first place? So it returns an ICMP redirect host 
> msg that tells you that you should have sent it to .39 in the first place.
> 
> This all makes sence to me, but what can we do? Is this the way it should 
> be or is there anything we can do about it?
> 
> One thought I have is, what if we do 1 instead, we drop packets destinated 
> for unknown IPs (for --dev tun, --topology subnet mode). It is a tun 
> interface so itīs not supposed to be bridged with any other networks, so 
> OpenVPN should know about all IP addresses that are in use already, right?

I agree that the packets should be dropped.

James


____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users