Routing and remote access VPN setup

Question

I am trying to set up VPN using routing and remote access.

I've tried two configurations, one using a single network card, and one using two network cards.

I can connect through my VPN and get assigned an IP address by the DHCP server, but I can't "SEE" anything. By this I mean the client appears completely blind to the office network, this means:

• No ping to any office server including the VPN server (I've stopped ICMP being filtered in and out)
• No DNS resolution (isn't surprising if I can't connect by IP address. I tried accessing the VPN Server Share and a web page hosted on it using the domain name and the IP address, e.g. http://host.com/abc and http://192.169.254.199/abc)
• Can't access any network resources (also not surprising given the above)

I've not had any problems connecting the VPN at all (I thought I had, but this was to do with the test router I given).

This doesn't appear to be a firewall/router problem as I configured it to allow VPN traffic through and forward to the correct server.

This, I think, is confirmed as the VPN server event logs shows success audits (that is, logon events).

However it does show the following event directly after the success audit logon event occurs (and I don't know if this is normal but wouldn't expect it to be - the VPN client doesn't disconnect).

An account was logged off.

Subject:
    Security ID:        [DomainName]\[UserName]
    Account Name:       [UserName]
    Account Domain:     [DomainName]
    Logon ID:       0x[xxxxxx]

Logon Type:         3

This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer.

I am not sure if this is of any use, but Wireshark shows me connecting successfully and then a load of encrypted packets, which is what I would suspect:

• There's a PPP LCP/CHAP configuration conversation which is the client connecting.
• I don't see any ICMP on either side when I do a ping to the VPN public interface (I assume this is because it is encapsulated on the GRE packets).

However the following is interesting (which I can't explain):

1. Pinging the public interface (A) (of VPN Server) I see increased PPP and GRE traffic
2. Same if I ping the private interface (B) (of VPN Server)
3. If I ping another server (C) on the network I can see the ICMP packet requests but no replies (I'm not sure if (C) server is replying directly to the VPN IP of the client (D) or not - this does appear the case as I see the traffic in (A))

I can't explain points 1 or 2 - I'd expect to see ICMP, but the problem does appear to be sending traffic to (D). To check this I pinged (D) from (C) and RECIEVED a reply, however I DID NOT see correlating ICMP traffic on (D) (could this have been GRE traffic?). I find this strange, but (C) is definitely pinging the correct machine as it stops responding when I disconnect (D) from the VPN.

Also note, I don't see any traffic on (D) to the VPN network addresses, only to the routers which have the port forwarding set up. Could this be some sort of routing problem?

The VPN server does seem to have a problem pinging the (D)- says NO RESOURCES, PathPing shows it is using interface (A). and this problem only occurs when pinging (D), it pings everything else without problem.

I changed RRAS to single NIC setup and the no resources problem went away - I can seemingly ping the client from all machines, but can't ping anything from the client. I say seemingly as when I ping the client it takes less than 1 ms (bear in mind this is across the Internet and different ISP's) and I don't see any ICMP traffic on the VPN server - plus when I disconnect the client, it is still pingable!?! (As if the VPN server is replying to pings on the client's behalf.) Whilst this is happening the VPN server gets timeouts when it pings the disconnected client. VERY STRANGE!

After leaving it for some time (drinking tea, eating food sort of length) the VPN server has gone back to the No resources problem, and not I have no ping in either direction. Disabling RRAS and enabling it again put me back to where I was just now, I can now ping from LAN to client.

Answer 1

Your terminology "...see anything on the LAN..." is imprecise. What do you mean by "see"? Do you mean that you couldn't PING or make TCP connections to hosts on the LAN? Do you mean that some "Network Places" or such functioinality didn't work?

What you're trying to do will work fine. You're probably not getting NetBIOS name resolution across the VPN because you're probably not using a WINS Server on the LAN. That would be my "psychic powers" guess as to why you're having problems.

Installing RRAS on a domain controller makes it multi-homed. It will work but Microsoft doesn't recommend it. You should think about preventing the RRAS adapter from registering in DNS and WINS.

Edit:

I don't think there's anything "contrived" about my answer. I'm trying to help based on your imprecise description of your problems (using the term "see" nstead of saying exactly what is failing when you're connected) and my experience with these types of problems. Your vague statement about using RADIUS gave me some feeling that you weren't a professional sysadmin (later validated by your comment re: your job) and that you were probably trying to use some graphical tool or application to access resources on the LAN but hadn't performed the basic troubleshooting steps of verifying layer 3 communication, name resolution, etc.

I've setup RRAS servers on domain controllers on LANs that are connected to the Internet behind NAT firewalls. I connect to them several times a week. What you're trying to do works fine.

Are you allowing the RRAS server to assign IP addresses to clients from DHCP, or have you specified an address range? If you've specified an address range is it a range that is within the LAN subnet, or is it a different subnet? Is the IP being assigned to the client when "connected" what you'd expect to see?

It's still unclear to me what you've tried doing once "connected" that makes you think you can't "see" the LAN. Can you PING the RRAS server's IP address? Can you make TCP connections to services hosted by the RRAS server or other servers on the LAN by IP address? Are you getting DNS resolution?

Finally, I did not suggest that moving RRAS to another server would make anything work. I suggested that Microosft doesn't recommend multi-homed domain controllers. RRAS will run fine on a domain controller, provided you understand the ramifications therewith.

Edit 2:

With the RRAS server setup to assign IP addresses from DHCP you're seeing a good LAN IP address being assigned to the client, then?

Assuming you are, and you can't PING the RRAS server's LAN IP address from the client, it's time to start sniffing traffic. I'd sniff on the RRAS server and on the client to see that the PING request is properly routing out the VPN connection (as an encrypted GRE payload-- presumably you're using PPTP). If sniffing is inconvenient you can watch the bytes transferred via the "Status" dialog for the connected client in the "Remote Access Clients" node in the "Routing and Remote Access" management console snap-in. I'd sniff, though-- there's no substitute for seeing the data on the wire.

The client's routing table looks like you'd expect after connection, too, I'd assume. By default, the Microsoft VPN client assigns your default gateway to the remote network (the "Use default gateway on remote network" checkbox in the "Advanced" TCP/IP properties for the VPN connection). If you turn that off, instead of seeing your default gateway change you'll see an entry for the remote network with a gateway of the IP address assigned to the client's VPN adapter. You don't mention what the client OS is, but the behaviour of the Microsoft VPN client changed slightly in Windows 7 (allowing you to disable the silly "classful" route addition behaviour explicitly).

It probably goes w/o asking, but the VPN server's LAN IP subnet and the LAN subnet where the client is connected are using different address ranges, aren't they?

Answer 2

This sounds to me like your VPN connection isn't configured properly. In order for a VPN to work, the client has to change some of its IP configuration details, particularly:

1. your name server has to be able to resolve names in the target network. This is generally achieved by having the VPN server forward the IP address of a suitable DNS server.
2. Your VPN server has to forward the relevant routes that are required to get traffic flowing. Usually a VPN connection operates on a very small (/30) subnet and your VPN server will handle the distribution into the various tunnels it holds. However, your client needs to know that IP address of the target network are reachable through the tunnel, and therefore additional routes are required in the clients routing table.
   

You can check this things as follows: while on the VPN, open a shell (DOS-prompt, whatever) on your client and run (under Windows)

ipconfig /all

or (under linux)

cat /etc/resolv.conf

This will show you which DNS server you are using. This DNS server either must reside on the target network (the most commonly used solution) or must be able to resolve names of machines in the target network to IP addresses.

The second test is to check your routing. Under Windows type

route print

Under Linux, use

sudo route -nv

This will give you output looking like this:

# route -nv
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.180.0.1      10.180.0.169    255.255.255.255 UGH   0      0        0 tun0
10.180.0.169    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.172.0.0      10.180.0.169    255.255.0.0     UG    0      0        0 tun0
10.171.0.0      10.180.0.169    255.255.0.0     UG    0      0        0 tun0
0.0.0.0         192.168.10.254  0.0.0.0         UG    0      0        0 eth0

In the above, the networks 10.171.0.0/16 and 10.172.0.0/16 are routed the tunnel.

If either of these two is missing on the client, then check your VPN server configuration, whether it acutally is set up to forward the relevant bits to the client. This obviously depends on the type of VPN server you are using.

Answer 3

I suggest changing your IP subnet. If you are IP address is 192.168.x.100 on your local network and you are trying to VPN into a remote site which also uses the x subnet, your problems could make sense.

Change your IP subnet. Not so easy I know...hahah.

Answer 4

It would appear to be a problem with DHCP traffic. I don't know why.

To resolve this I MANUALLY added a static address pool (it won't work if you configure it like this when setting up RRAS).

Now I can ping. Though DNS seems to be a problem even though the correct DNS servers are picked up by the client - to solve this you need to configure the VPN network connection on the client to append DNS suffix.