OpenVPN connects but traffic is not handling by the tunnel

[atsiha]

I've set up an OpenVPN server using instructions below:

http://www.emaculation.com/doku.php/bri ... rver_setup

Although I didn't get the exact point of "Port Forwarding" section and didn't do anything about that, except enabling it over IPv4 at the server side, I've got successfully connected to it from the internet, but no traffic goes inside this server and I'm receiving data from my own internet line.

I myself doubt about the "Port Forwarding" and IP settings, but actually don't know what's going on and why this happens.

Here is my server.conf file:

Code: Select all

port 1194
proto udp
dev tap0
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
remote-cert-tls client
server-bridge 172.16.36.100 255.255.255.0 172.16.36.101 172.16.36.110
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 3

And here is the client.ovpn file:

Code: Select all

client
dev tap0
proto udp
remote 60.50.40.190 1194
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
comp-lzo
verb 3

There also is a openvpn-bridge file script that I've modified as below:

Code: Select all

#!/bin/sh

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"

# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth_ip="60.50.40.190"
eth_netmask="255.255.255.248"
eth_broadcast="60.50.40.191"
eth_gateway="60.50.40.185"

case "$1" in
start)
    for t in $tap; do
        openvpn --mktun --dev $t
    done

    brctl addbr $br
    brctl addif $br $eth

    for t in $tap; do
        brctl addif $br $t
    done

    for t in $tap; do
        ifconfig $t 0.0.0.0 promisc up
    done

    sleep 1

    ifconfig $eth 0.0.0.0 promisc up

    sleep 1

    ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

    sleep 1

    route add default gw $eth_gateway
    ;;
stop)
    ifconfig $br down
    brctl delbr $br

    for t in $tap; do
        openvpn --rmtun --dev $t
    done

    ifconfig $eth $eth_ip netmask $eth_netmask broadcast $eth_broadcast

    route add default gw $eth_gateway
    ;;
*)
    echo "Usage:  openvpn-bridge {start|stop}"
    exit 1
    ;;
esac
exit 0

Assuming that sample 60.50.40.190 is valid IP address of my server on internet and what is set on its eth0 network interface.

There also is something to report and that's the br0 and tap0 interfaces which are still displayed at the output of ifconfig after stopping openvpn service and it's against what mentioned at instructions.

[atsiha]

I've just seen the forum rules on the top and below line drew my attention:

**You ONLY want to use dev tap if you are tunneling layer2 traffic, if you are using IP traffic you want tun. If you are using tap only for windows file sharing, look into running a WINS server instead.

Is that all about my problem? I've actually set up this way because of playing LAN games over OpenVPN on internet and I've needed it to relay broadcast packages just like a normal LAN.

[Traffic]

br0 and tap0 interfaces which are still displayed at the output of ifconfig

Please post ifconfig details.

Is this a hosted or private server ?

[atsiha]

br0 and tap0 interfaces which are still displayed at the output of ifconfig

Please post ifconfig details.

Is this a hosted or private server ?

It's a VM on my ESXi server and it has a valid public IP. Here is the ifconfig output:

[Traffic]

From our documentation:

Make sure to only bridge TAP interfaces with private ethernet interfaces which are protected behind a firewall. Never bridge a TAP interface with the same ethernet interface you use to connect to the internet

See:
https://openvpn.net/index.php/open-sour ... dging.html

[atsiha]

From our documentation:

Make sure to only bridge TAP interfaces with private ethernet interfaces which are protected behind a firewall. Never bridge a TAP interface with the same ethernet interface you use to connect to the internet

See:
https://openvpn.net/index.php/open-sour ... dging.html

So you mean I need to add another NIC and also enable the firewall? If so, what rules should I add to the iptables?

[Traffic]

It's a VM on my ESXi server and it has a valid public IP

Is the Host for the VM a privately owned server or a VMS / VZ server from a hosting company ?

[atsiha]

It's a VM on my ESXi server and it has a valid public IP

Is the Host for the VM a privately owned server or a VMS / VZ server from a hosting company ?

It's my own rented dedicated server from our data center partner which VMware ESXi installed on.

[Traffic]

Is eth0 directly connected to the internet with a public IP address or is it behind a firewall ?

[atsiha]

Is eth0 directly connected to the internet with a public IP address or is it behind a firewall ?

No, It's directly connected with a public IP address. There is no firewall.

[Traffic]

I've actually set up this way because of playing LAN games over OpenVPN

I suggest you do it internally to the LAN before your ISP shuts your internet down for flooding the segment ... use a test machine not a production system.

[atsiha]

I've actually set up this way because of playing LAN games over OpenVPN

I suggest you do it internally to the LAN before your ISP shuts your internet down for flooding the segment ... use a test machine not a production system.

They wouldn't do that with their partner which has 300+ dedicated servers on their data center! By the way, you mean I can not have this server over internet?

You also didn't answer my previous question about requirement of using 2 NIC on this server. Should I add one more virtual NIC and bridge the tap adapter with the second NIC which uses a private IP range?

[Traffic]

They would if you break their T&C's ..

[atsiha]

They would if you break their T&C's ..

No, I guess you're wrong because you may thought my server is behind their firewall and they are blocking my UDP broadcast packets, but this is not true.

I've reformatted and reconfigured the server using two NICs and here are my new configuration files:

/etc/network/interfaces :

Code: Select all

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
        address 192.168.5.100
        netmask 255.255.255.0
allow-hotplug eth1
iface eth1 inet static
        address 60.50.40.190
        netmask 255.255.255.248
        network 60.50.40.184
        broadcast 60.50.40.191
        gateway 60.50.40.185
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 8.8.8.8 8.8.4.4
        dns-search sub.domain.tld

/etc/openvpn/openvpn-bridge :

Code: Select all

br="br0"
tap="tap0"
eth="eth0"
eth_ip="192.168.5.100"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.5.255"
eth_gateway="60.50.40.185"
case "$1" in
start)
    for t in $tap; do
        openvpn --mktun --dev $t
    done
    brctl addbr $br
    brctl addif $br $eth
    for t in $tap; do
        brctl addif $br $t
    done
    for t in $tap; do
        ifconfig $t 0.0.0.0 promisc up
    done
    ifconfig $eth 0.0.0.0 promisc up
    ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast
    sleep 1
    route add default gw $eth_gateway
    ;;
stop)
    ifconfig $br down
    brctl delbr $br
    for t in $tap; do
        openvpn --rmtun --dev $t
    done
    ifconfig $eth $eth_ip netmask $eth_netmask broadcast $eth_broadcast
    route add default gw $eth_gateway
    ;;
*)
    echo "Usage:  openvpn-bridge {start|stop}"
    exit 1
    ;;
esac
exit 0

/etc/openvpn/server.conf :

Code: Select all

port 1194
proto udp
dev tap0
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
remote-cert-tls client
server-bridge 192.168.5.100 255.255.255.0 192.168.5.101 192.168.5.110
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 3

Now, there is no problem with ifconfig or ... but the traffic still goes through my internet line not the openvpn server. I'm really confused why this happens and where did I mistake.

Any idea?

[atsiha]

and there is an ifconfig output:

[atsiha]

according to the Troubleshooting section of the instructions, I've found that no packets are passing through the openvpn port. I've used the command below:

Code: Select all

tcpdump -ni br0 port 1194

but there is nothing displayed while connecting and using openvpn client, but I didn't have this problem before! I think there is something wrong with my settings.

[Traffic]

if you are in fact qualified to be doing this .. I suggest you read the documentation carefully.

Otherwise, I recommend you consult your immediate superiors before you do something you regret.

[atsiha]

Any other idea to really solve my problem?!

[Traffic]

I've used the command below:

Code:
tcpdump -ni br0 port 1194


but there is nothing displayed while connecting and using openvpn client

If you see no packets then you have a network problem .. openvpn is not even in the equation yet.

[atsiha]

I've used the command below:

Code:
tcpdump -ni br0 port 1194


but there is nothing displayed while connecting and using openvpn client

If you see no packets then you have a network problem .. openvpn is not even in the equation yet.

I've followed several instructions about configuring such a thing and still had no success! Here is my network schema:



The whole network is on internet and the OpenVPN server has a valid public IP address. I need clients to be able to play games with each other, so the VPN should act like a normal LAN and pass everything like UDP broadcast packets through itself and share with other clients.

I think I'm doing something wrong about bridging, however I've tried different things. The instructions are most done on a LAN or Home network and none of them had the same situation as mine.