2

I have a first computer, running Windows Server 2019 and called Win2019 that has two interfaces:

  1. Ethernet has received 192.168.1.1 as it is connected to a network which address is 192.168.1.0/24 on which the gateway is 192.168.1.254
  2. Ethernet0 has received 10.0.0.148 as it is connected to another network which address is 10.0.0.0/24 on which the gateway is 10.0.0.254

I also have a second computer, this time running Windows 10 and called Win10 which has a single interface which received 10.0.0.1 as it is connected to the same 10.0.0.0/24 network mentioned above.

My goal is to allow the Win10 computer to connect to network shares in the 192.168.1.0/24 network and so I am trying to configure the Win2019 machine to act as a router between the two networks it knows about.

To achieve that, I added the RRAS role on the Win2019 machine and configured it manually in the IPv4 NAT section by adding the Ethernet and Ethernet0 interfaces, the first being setup as "Public network with NAT activated" and the second as "Private network".

Then, on the Win10 computer, I manually added this route:

route add 192.168.1.0 mask 255.255.255.0 10.0.0.148 metric 25

And I directly tried to ping the 192.168.1.17 machine with the following results:

  • On the Win2019 machine, I received the replies just fine
  • On the Win10 host, I had 100% packets lost

I thus started up WireShark on both machines and tried again pinging 192.168.1.17 from the Win10 machine and observed the following:

  1. The ICMP echo request packet is seen on the 10.0.0.1 interface (Win10)
  2. The ICMP echo request packet is seen on the 10.0.0.148 interface (Ethernet0, Win2019)
  3. The ICMP echo reply packet is seen on the 10.0.0.148 interface (Ethernet0, Win2019)

I also tried a telnet on port 139 and the same happens with the SYN and SYN/ACK packets, it's as if the packets are not properly placed back on the 10.0.0.0/24 network.

Clearly, I have missed a setting somewhere, but I fail to see which one.

For reference this is the route table on the Win2019 machine:

      0.0.0.0            0.0.0.0       10.0.0.254       10.0.0.148     25
      0.0.0.0            0.0.0.0    192.168.1.254      192.168.1.1      2
     10.0.0.0      255.255.255.0         On-link        10.0.0.148    281
   10.0.0.148    255.255.255.255         On-link        10.0.0.148    281
   10.0.0.255    255.255.255.255         On-link        10.0.0.148    281
192.168.1.255    255.255.255.255         On-link       192.168.1.1    257

And the one on the Win10 machine after I manually added the route mentioned above:

          0.0.0.0          0.0.0.0       10.0.0.254         10.0.0.1     25
         10.0.0.0    255.255.255.0         On-link          10.0.0.1    281
         10.0.0.1  255.255.255.255         On-link          10.0.0.1    281
       10.0.0.255  255.255.255.255         On-link          10.0.0.1    281
      192.168.7.0    255.255.255.0       10.0.0.148         10.0.0.1     50

Any help, pointers, would be much appreciated

OBones
  • 183
  • 7

1 Answers1

0

The 192.168.1.1 interface is managed by a VPN client software which I did not mention above because I thought it would not have an impact. But when the VPN connection is down, I can properly use the 10.0.0.148 interface, and as soon as the VPN is up, nothing much comes through.

This got me thinking about this:

it's as if the packets are not properly placed back on the 10.0.0.0/24 network

So I went into the 10.0.0.148 network card properties and so an item in there called "VPN Software NDIS filter". And sure enough, as soon as I disabled it, the packets came back on the 10.0.0.148 interface. Sadly, this also meant that the VPN connection was no longer working, thus rendering the whole setup useless.

Luckily for me, I was able to add a second network card to the Win2019 machine, plugged on the same 10.0.0.0/24 network which received the 10.0.0.150 IP address. I then disabled the filter mentioned above on that new network card, which allowed the VPN software to function properly while allowing the routing of packets to work a the same time!

So, in the end, it's the VPN filter that clearly was preventing the packets from going through, but using the second card trick is the solution.

OBones
  • 183
  • 7