Client to Client connections not working properly.

stewi1014

Hello,
I am failing at getting client to client connections to work they way they should.
In short, what I want to achieve:

1. (working) Create a secure VPN that will allow the administration of the server through services like webmin and SSH through an extra layer of security (VPN SSL).

2. (working) Allow routing of all traffic through the server, using it as a gateway (through the use of an alternative client config with 'redirect-gateway def1')

3. (not working) Allow unhindered connection between all clients on the VPN, as to allow LAN Gaming EXCLUSIVELY over the VPN.

I have seen many people asking about this, and the common response is ethernet bridging. I get the idea that ethernet bridging is for connecting a LAN to the VPN, as to allow seamless connection between LAN clients and VPN clients. My VPS is not on a private subnet nor is it a gateway for one and it is certanly not a DHCP server (except for the VPN).

This is a poorly drawn illustration of the setup: http://lenqua.net/VPN.png

pings from client to client usually work, but fail on certain clients, even from the server. Pings from clients to the server never fail.
Pinging from .24 to .4 gets ping packets showing on tcpdump -i tap0 host 10.8.0.24,
but nothing on tcpdump -i tap0 host 10.8.0.4, and pings form the server to .4 don't work either.

Is ethernet bridging really what I want? By my understanding bridging is for connecting VPN clients to a LAN, as in a office setting, where clients can connect to the VPN and it is as if they are actually connected the the office network. My server is exclusively connected directly to the internet, no LAN to bridge to.

Any help with understanding/fixing this would be greatly appreciated.

- Stewi.

Traffic

stewi1014 wrote2. (working) Allow routing of all traffic through the server, using it as a gateway (through the use of an alternative client config with 'redirect-gateway def1')

3. (not working) Allow unhindered connection between all clients on the VPN, as to allow LAN Gaming EXCLUSIVELY over the VPN.

Looks like a conflict of interests here ..

If you redirect your client gateways .: you cannot use VPN EXCLUSIVELY for gaming.

stewi1014

When I say "allow LAN Gaming EXCLUSIVELY over the VPN" I mean that I have no LAN that I want to bridge to the VPN, and that the LAN Gaming will only be done on the VPN, no other network. That is not to say that is the only thing the VPN will do.

That is unless I'm misunderstanding you...

Traffic

So the real problem is you have no server LAN to bridge your TAP adapter to ?

You can use TAP without a bridge so try it .. do not bridge with your WAN adapter though !

stewi1014

Like what I currently have set up?

I'm not sure I understand. "You can use TAP without a bridge so try it" I thought that was what I was already doing, and it just isn't working for client to client connections. I have dev tap in the server and all client configs, and I haven't set up any kind of bridging. Everything except client to client connections are working properly.

I have ipv4 forwarding set in sysctl.conf, and the firewall is not blocking the packets (have tried with firewall turned off).
I do however remember observing at one point seeing ping packets being lost in the server (tcpdump showed icmp packets being received, but not passed onto the respective client). I am not sure if it was something I was testing at the time that caused this or not. I will try reproduce it. The most predominant problem is ping packets that are sent to certain clients don't get a reply back. I am aware that windows firewall may be blocking this, but all other forms of traffic seem to be block as well.

Client config:
http://pastebin.com/kL5995E0

Server config:
http://pastebin.com/QySCeyiL

output of route print -4 on windows:
http://pastebin.com/7XQfWGPq

What gets me is under gateway it says On-Link, which I looked up and apparently it means that "They are addresses that can be resolved locally. They don't need a gateway because they don't need to be routed." - MDMarra on superuser.com

Traffic for the VPN doesn't need a gateway because it doesn't need to be routed?
What a load of rubbish.
Is there something I am missing? Or are are the client routing tables actually incorrect. If so, how would I go about fixing it.
I already tried route-gateway 10.8.0.1, route-delay 30, route-method exe as well as using route-metric <15,20,200>.

Traffic

stewi1014 wroteI'm not sure I understand. "You can use TAP without a bridge so try it" I thought that was what I was already doing

You had not posted configs so I had no way to know that ...

Best practice for posting:

Server config:
* There is no identifiable or exploitable information here

    ;local a.b.c.d
    proto udp
    dev tap
    ca ca.crt
    cert server.crt
    key server.key  # This file should be kept secret
    dh dh2048.pem
    server 10.8.0.0 255.255.255.0
    ifconfig-pool-persist ipp.txt
    push "dhcp-option DNS 8.8.4.4"
    push "dhcp-option DNS 8.8.8.8"
    client-to-client
    keepalive 10 120
    ;tls-auth ta.key 0 # This file is secret  ## Enable this !
    persist-key
    persist-tun   ### You may aswell use this as well
    status openvpn-status.log
    verb 3
     
    topology subnet  ### --topology subnet is always used for --dev tap
    push "topology subnet"  ### --topology is automatically pushed when --server is used

I highly recommend you include a --tls-auth key dir for real security.

See --tls-auth in The Manual v23x

Client config:
* Identifiable information redacted

client
    dev tap
    proto udp
    remote name.redacted 8080
    resolv-retry infinite
    nobind
    persist-key
    remote-cert-tls server
    route-method exe
    route-gateway 10.8.0.1  ## Remove this as it is correctly pushed from the server
    route-metric 2  ## Remove this unless you know what you are doing
    route-delay 30
     
    ca ca.crt
    cert cert.crt
    key key.key

stewi1014 wroteare the client routing tables actually incorrect

Client route:
* Identifiable data obscured

	

    IPv4 Route Table
    ===========================================================================
    Active Routes:
    Network Destination        Netmask          Gateway       Interface  Metric
              0.0.0.0          0.0.0.0         25.0.0.1        #.#.#.253   9256
              0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.10     20
             10.8.0.0    255.255.255.0         On-link          10.8.0.8    276
             10.8.0.8  255.255.255.255         On-link          10.8.0.8    276
           10.8.0.255  255.255.255.255         On-link          10.8.0.8    276
             25.0.0.0        255.0.0.0         On-link         #.#.#.253   9256
            #.#.#.253  255.255.255.255         On-link         #.#.#.253   9256
       25.255.255.255  255.255.255.255         On-link         #.#.#.253   9256
            127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
            127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
      127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
          192.168.1.0    255.255.255.0         On-link      192.168.1.10    276
         192.168.1.10  255.255.255.255         On-link      192.168.1.10    276
        192.168.1.255  255.255.255.255         On-link      192.168.1.10    276
         192.168.56.0    255.255.255.0         On-link      192.168.56.1    276
         192.168.56.1  255.255.255.255         On-link      192.168.56.1    276
       192.168.56.255  255.255.255.255         On-link      192.168.56.1    276
            224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
            224.0.0.0        240.0.0.0         On-link      192.168.56.1    276
            224.0.0.0        240.0.0.0         On-link      192.168.1.10    276
            224.0.0.0        240.0.0.0         On-link         #.#.#.253   9256
            224.0.0.0        240.0.0.0         On-link          10.8.0.8    276
      255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      255.255.255.255  255.255.255.255         On-link      192.168.56.1    276
      255.255.255.255  255.255.255.255         On-link      192.168.1.10    276
      255.255.255.255  255.255.255.255         On-link         #.#.#.253   9256
      255.255.255.255  255.255.255.255         On-link          10.8.0.8    276

Your client route table appears to be in order ..

However, where are 192.168.1.0/24 and 192.168.56.0/24 located ?

Also, what OS is your server ?

Onlink means:

stewi1014 wroteThey are addresses that can be resolved locally. They don't need a gateway because they don't need to be routed

This is correct ...

For now: Please post your server & client log files ..
Take your time and clean out any identifiable data you want to remove.

stewi1014

These are the server and client log files. You're right I should have been more careful with the configs I posted earlier, however I'm not exactly wanting to rely on obscurity for security.

Client Log:
http://pastebin.com/eBdQx2YG

Server Log:
http://pastebin.com/sUyMTk44

Traffic

stewi1014 wrote3. (not working) Allow unhindered connection between all clients on the VPN, as to allow LAN Gaming EXCLUSIVELY over the VPN.

works for me ..

Other than the default setting in server.conf try this:

dev tap
local your.public.ip                 ## my test was 172.17.2.199 .. yours must be your public ip
port you.decide                      ## my test was 14950
client-to-client
server 10.149.50.0 255.255.255.0     ## choose your own rfc1918 compliant network.
topology subnet

everything else can be default .. for now.

Obviously, include a full PKI and I strongly advise with --tls-auth key.

enable ip_forward

and you should be good to go .. no bridge required.

My setup

wxp client #1:

Ethernet adapter OVPN:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : TAP-Windows Adapter V9
        Physical Address. . . . . . . . . : 00-FF-F5-9C-83-CA
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 10.149.50.2
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . :
        DHCP Server . . . . . . . . . . . : 10.149.50.0
        Lease Obtained. . . . . . . . . . : 10 January 2015 21:05:10
        Lease Expires . . . . . . . . . . : 10 January 2016 21:05:10

linux server: no bridge (WAN-IP:172.17.2.199 :o: port:14950)

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.149.50.1  netmask 255.255.255.0  broadcast 10.149.50.255
        ether 36:3b:29:7c:38:73  txqueuelen 100  (Ethernet)
        RX packets 70  bytes 16051 (15.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12  bytes 6616 (6.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

netstat:

[root@arch-d-test openvpn]# ns
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 172.17.2.199:14950      0.0.0.0:*                           1641/openvpn

linux client #2:

tap0      Link encap:Ethernet  HWaddr c2:d6:91:0e:15:d5
          inet addr:10.149.50.3  Bcast:10.149.50.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:80 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:17055 (16.6 KiB)  TX bytes:8772 (8.5 KiB)

Ping

client #1 -> client #2

Reply from 10.149.50.3: bytes=32 time=30ms TTL=64
Reply from 10.149.50.3: bytes=32 time=10ms TTL=64
Reply from 10.149.50.3: bytes=32 time=10ms TTL=64
Reply from 10.149.50.3: bytes=32 time=16ms TTL=64

Ping statistics for 10.149.50.3:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

client #2 -> client #1

PING 10.149.50.2 (10.149.50.2) 56(84) bytes of data.
64 bytes from 10.149.50.2: icmp_req=1 ttl=128 time=12.9 ms
64 bytes from 10.149.50.2: icmp_req=2 ttl=128 time=12.2 ms
64 bytes from 10.149.50.2: icmp_req=3 ttl=128 time=12.8 ms

--- 10.149.50.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms

As an indication of tap functionality:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:36:52.614738 IP 10.149.50.2.138 > 10.149.50.255.138: NBT UDP PACKET(138)

stewi1014

Ok, thanks for that, I'll try it and make sure to use --tls-auth too. I think it may be an OS/networking issue. While setting up a diferent VPN server, the guide I was following got me to do some pretty core changes. I bookmarked it so I could undo them later and I thought I undid most of them when I moved to OpenVPN, but I'll check. I'll also ask around the ubuntu IRC channels and go over the server networking configs with a fine tooth comb. Thanks again. I'll post here if I find an answer.