tap-windows6
tap-windows6 copied to clipboard
OpenVPN
IPV4 - routes, and such - confused
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:
Unknown adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TAP-Windows Adapter V9
Physical Address. . . . . . . . . : 00-FF-0D-20-6E-9E
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::456:c9a:9c24:6df3%17(Preferred)
IPv4 Address. . . . . . . . . . . : 10.168.42.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.252
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 285277965
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-2F-CD-E0-98-E7-43-7A-1E-F9
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled
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:
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.168.99.1 10.168.99.195 25
10.168.42.0 255.255.255.252 On-link 10.168.42.1 281
10.168.96.0 255.255.252.0 On-link 10.168.99.195 281
10.168.99.195 255.255.255.255 On-link 10.168.99.195 281
10.168.99.255 255.255.255.255 On-link 10.168.99.195 281
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
169.254.0.0 255.255.0.0 On-link 169.254.13.25 281
169.254.13.25 255.255.255.255 On-link 169.254.13.25 281
169.254.255.255 255.255.255.255 On-link 169.254.13.25 281
192.168.56.0 255.255.255.0 On-link 192.168.56.1 281
192.168.56.1 255.255.255.255 On-link 192.168.56.1 281
192.168.56.255 255.255.255.255 On-link 192.168.56.1 281
192.168.125.0 255.255.255.0 On-link 192.168.125.1 291
192.168.125.1 255.255.255.255 On-link 192.168.125.1 291
192.168.125.255 255.255.255.255 On-link 192.168.125.1 291
192.168.162.0 255.255.255.0 On-link 192.168.162.1 291
192.168.162.1 255.255.255.255 On-link 192.168.162.1 291
192.168.162.255 255.255.255.255 On-link 192.168.162.1 291
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.56.1 281
224.0.0.0 240.0.0.0 On-link 192.168.125.1 291
224.0.0.0 240.0.0.0 On-link 192.168.162.1 291
224.0.0.0 240.0.0.0 On-link 10.168.99.195 281
224.0.0.0 240.0.0.0 On-link 169.254.13.25 281
224.0.0.0 240.0.0.0 On-link 10.168.42.1 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.56.1 281
255.255.255.255 255.255.255.255 On-link 192.168.125.1 291
255.255.255.255 255.255.255.255 On-link 192.168.162.1 291
255.255.255.255 255.255.255.255 On-link 10.168.99.195 281
255.255.255.255 255.255.255.255 On-link 169.254.13.25 281
255.255.255.255 255.255.255.255 On-link 10.168.42.1 281
===========================================================================
Persistent Routes:
None
I have 3 tests I've tried:
Method 1: ping 10.168.42.2 - I would expect some activity
Method 2: ping -6 -S localipv6address someipv6addressonnetwork
Method 3: curl -o foo http://10.168.42.2
For 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.
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 [email protected]
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
//=====================================================
// Are we running in DHCP server masquerade mode?
//
// If so, catch both DHCP requests and ARP queries
// to resolve the address of our virtual DHCP server.
//=====================================================
if (Adapter->m_dhcp_enabled)
{
const ETH_HEADER *eth = (ETH_HEADER *) tapPacket->m_Data;
const IPHDR *ip = (IPHDR *) (tapPacket->m_Data + sizeof (ETH_HEADER));
const UDPHDR *udp = (UDPHDR *) (tapPacket->m_Data + sizeof (ETH_HEADER) + sizeof (IPHDR));
// ARP packet?
if (packetLength == sizeof (ARP_PACKET)
&& eth->proto == htons (NDIS_ETH_TYPE_ARP)
&& Adapter->m_dhcp_server_arp
)
{
if (ProcessARP(
Adapter,
, or case (B) line 662 - This part is confusing the COMMENT states one thing, but the code reads the reverse. - confused.
//===============================================
// In Point-To-Point mode, check to see whether
// packet is ARP (handled) or IPv4 (sent to app).
// IPv6 packets are inspected for neighbour discovery
// (to be handled locally), and the rest is forwarded
// all other protocols are dropped
//=============================================== if (Adapter->m_tun)
{
ETH_HEADER *e;
e = (ETH_HEADER *) tapPacket->m_Data;
switch (ntohs (e->proto))
{
case NDIS_ETH_TYPE_ARP:
// Make sure that packet is the right size for ARP.
if (packetLength != sizeof (ARP_PACKET))
{
goto no_queue;
}
ProcessARP (
Adapter,
.... snip snip ...
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 [email protected]
@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?
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
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)
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 = TRUEoccurs 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 [email protected]
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 [email protected]
Still no joy.
Enabling the DHCP server seems to work, the adapter is configured now :-) via dhcp In wire shark I do see the DHCP requests... and the ack.
And in wireshark I see the ARP requests for .2 but I don't see replies.
Unknown adapter TAP_TUN:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TAP-Windows Adapter V9
Physical Address. . . . . . . . . : 00-FF-0D-20-6E-9E
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::456:c9a:9c24:6df3%4(Preferred)
IPv4 Address. . . . . . . . . . . : 10.168.42.1(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.252
Lease Obtained. . . . . . . . . . : Tuesday, March 31, 2020 11:52:07 AM
Lease Expires . . . . . . . . . . : Wednesday, April 1, 2020 11:52:07 AM
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 10.168.41.255
DHCPv6 IAID . . . . . . . . . . . : 285277965
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-2F-CD-E0-98-E7-43-7A-1E-F9
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled
The ARP output, ie: arp -a -v gives this, I don't know why the .2 address says: Invalid.
C:\Windows\system32>arp -a -v
Interface: 127.0.0.1 --- 0x1
Internet Address Physical Address Type
224.0.0.22 static
239.255.255.250 static
Interface: 10.168.42.1 --- 0x4
Internet Address Physical Address Type
10.168.42.2 00-00-00-00-00-00 invalid
10.168.42.3 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static
224.0.0.252 01-00-5e-00-00-fc static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static