IPV4 - routes, and such - confused #111
Comments
|
Hi,
On Mon, Mar 30, 2020 at 06:04:17PM -0700, duaneellissd wrote:
I'm not getting any IPV4 packets out of the TUN driver in P2P mode.
I don't understand why and I am a bit confused.
This looks like "ARP fail". Try wiresharking on the tun interface to
see what happens.
My bet is on "before sending the IPv4 ping, you see an ARP request, which
is not answered, thus the IP layer has no idea where on that virtual
ethernet it's supposed to send the IPv4 packet to".
You can try to set up startic ARP entries, though I'm not sure if that
works right. What OpenVPN does is to program the "gateway" IPv4 address
into the tun/tap driver by means of an ioctl(), and so the driver itself
answers the ARP request with its own MAC adddress, and then IPv4 can flow.
IPv6 is different because for ND, IPv6 packets are used that are sent
to multicast addresses = forwarded everywhere without destination MAC
address resolution first.
See openvpn's tun.c, tuntap_set_ptp() for the DeviceIoControl() calls
used (git master, but searching for TAP_WIN_IOCTL_CONFIG_TUN should
find it in 2.4 as well).
(The .1 / .2 thing is just a simplistic check to ensure "common subnet"
- larger subnets and other numbers work fine, just no true point-to-point
mode with arbitrary addresses, they must be "in a common subnet")
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
|
Agree it's an ARP problem, I think it is a design limitation - I am using P2P Mode, not TUN mode. I am not using DHCP, perhaps I should I would have expected P2P mode to "just work" - I think the problem is described below I see this in Wireshark:
I believe the AUTOIP address (169.254) is the default address given at startup. When I start the adapter (ie: ioctl(set media state) I see the two gratuitous ARPs Then later, I try to PING the remote side, I then see the three "Who has" ARP requests, but nothing comes out of the driver into my user space app. Looking at the code in "device.c" - I find the function ProcessARP() which seems to send the ARP reply, it lives in the txpath.c - it is called under 2 conditions: (A) Line 597 - if DHCP is enabled, I'm not enabling it , or case (B) line 662 - This part is confusing the COMMENT states one thing, but the code reads the reverse. - confused. |
|
Hi,
On Tue, Mar 31, 2020 at 09:07:24AM -0700, duaneellissd wrote:
Agree it's an ARP problem, I think it is a design limitation -
I am using P2P Mode, not TUN mode. I am not using DHCP, perhaps I should
From windows' point of view, this is an "Ethernet" interface, so whatever
you do, you need to make ARP work.
There is no "p2p" mode on the tap driver side (which is why there are
restrictions on subnet mask, ip addresses, etc.). It is an ethernet,
which needs to do ARP resolution before packets can be sent to the
remote side.
It is what it is, whether we like it or not.
There *is* "TUN" vs "TAP" mode on the TAP driver side, which differs in
"will the client application see ethernet headers or just IPv4/IPv6"
(in TAP mode, you'd see the ARP).
When I start the adapter (ie: ioctl(set media state) I see the two gratuitous ARPs
Then later, I try to PING the remote side, I then see the three "Who has" ARP requests, but nothing comes out of the driver into my user space app.
Sure, because you need to tell(!) the driver which address to reply to.
It will ignore ARP for all IPv4 addresses except the one that you've
ioctl()'ed in.
gert
…--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
|
@gert - Thanks that helps me understand the problem I also see that that in the P2P case, the Question 1: what sends the Gratuitous ARP at startup - The driver or windows? Question 2: Would the fact the driver seems to have 2 IP address (the auto-ip + configured) be the problem, I donot for example see a loop that tests: "For all configured ip address on this driver" thus it would never capture the second address (The first I assume is the AUTO-IP, the SECOND I assume is the configured address) Question 3: Can you explain the DHCP side? I can turn that on if it helps - I got the impression and I could be wrong - that it needs to work with the remote side DHCP server... or something like that. In my case my remote does not have a DHCP server, it's a really dumb micro controller running LWIP/SLIP - do I really need to run a dhcp server on that board to make this work? In any case - If I enable the DHCP - I want to pass the correct parameters - Looking at the driver code, it looks like there are 4 parameters to the DHCP server call. Value 0 - the DHCP address, Value 1 = The DHCP Netmask, value 3 = The DHCP Server IP, Value 4 = the lease time in seconds. |
|
@cron2 (Gert) - Follow up question
Where exactly do I do this, when I configure for P2P - there are 2 parameters
Edit - Its not _at_gert, it is _at_cron2... |
|
Hi,
On Tue, Mar 31, 2020 at 09:45:58AM -0700, duaneellissd wrote:
@gert - Thanks that helps me understand the problem
I also see that that in the P2P case, the ``adapter->m_tun = TRUE`` occurs my bad there.
Question 1: what sends the Gratuitous ARP at startup - The driver or windows?
That's windows - duplicate address detecion and such.
Question 2: Would the fact the driver seems to have 2 IP address (the auto-ip + configured) be the problem, I donot for example see a loop that tests: "For all configured ip address on this driver" thus it would never capture the second address (The first I assume is the AUTO-IP, the SECOND I assume is the configured address)
auto-ip should only be seen if you have configured the interface in windows
to "automatic address assignment" - which is only useful if you use the
virtual DHCP server built into the TAP driver.
Question 3: Can you explain the DHCP side? I can turn that on if it helps - I got the impression and I could be wrong - that it needs to work with the remote side DHCP server... or something like that.
The TAP driver can pretend to be a DHCP server, to assign the address to
the TAP interface. It's enabled by ioctl() calls from the controlling
application.
In my case my remote does not have a DHCP server, it's a really dumb micro controller running LWIP/SLIP - do I really need to run a dhcp server on that board to make this work?
No.
In any case - If I enable the DHCP - I want to pass the correct parameters - Looking at the driver code, it looks like there are 4 parameters to the DHCP server call. Value 0 - the DHCP address, Value 1 = The DHCP Netmask, value 3 = The DHCP Server IP, Value 4 = the lease time in seconds.
Not sure which call you are talking about. The relevant bits are
the ioctl() calls in openvpn's tun.c code - they demonstrate how to use
the driver for the different scenarios.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
|
Hi,
On Tue, Mar 31, 2020 at 09:51:55AM -0700, duaneellissd wrote:
@gert - Follow up question
>> Sure, because you need to tell(!) the driver which address to reply to.
Where exactly do I do this, when I configure for P2P - there are 2 parameters
- Parameter 0 - is the local IP - I presume that is the IP address of the local interface, which in my case is 10.168.42.1 (I pass this, the .1 address) - the remote device is 10.168.42.2 (not setting this)
- Parameter 1 is the netmask, which is 255.255.255.252 (0xfffffffc)
I'm not sure which of the DeviceIoControl()s will effectively store the
"other end IP" in the TAP driver, and what exactly "POINT_TO_POINT"
will do under the hood - it's a bit convoluted, and in this context,
"p2p" might not do what you expect (given that for windows this will
always be a network segment with a broadcast address).
Also, OpenVPN calls this "remote_netmask" for a good reason - the
variable can be "remote" or "netmask", and in the p2p context it's quite
likely "remote". So, put 10.168.42.2 in parameter 1 and see what happens.
gert
…--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany gert@greenie.muc.de
|
|
Still no joy. Enabling the DHCP server seems to work, the adapter is configured now :-) via dhcp And in wireshark I see the ARP requests for .2 but I don't see replies. The ARP output, ie: |
I'm not getting any IPV4 packets out of the TUN driver in P2P mode.
I don't understand why and I am a bit confused.
It seems that no matter what I do, I do not get IPv4 Traffic - I see IPv6 but no IPv4
What I don't know how to do is determine the route windows wants to use.
Interface configuration:
I read in the OpenVPN source code that, in P2P mode, the network mask must be exactly 255.255.255.252 - so that's what I have.
I also see in the same code, the IP address for the WINDOWS side (last bits) must be 1 or 2, and the REMOTE side must be the other 2 or 1.
Thus, I configured the windows interface as 10.168.42.1, my remote side is 10.168.42.2
The ROUTING TABLES are as follows:
I have 3 tests I've tried:
Method 1:
ping 10.168.42.2- I would expect some activityMethod 2:
ping -6 -S localipv6address someipv6addressonnetworkMethod 3:
curl -o foo http://10.168.42.2For case 2, The IPv6 seems to work using linked local addresse (fe80), and specifying the target address as the same as the ipv6 addres but +1, thus it is on the same IPv6 segment. This works, I see packets out of the tun driver but no IPv4 packets.
The text was updated successfully, but these errors were encountered: