Koozali.org formerly Contribs.org

Using OPENVPN

achandra

Using OPENVPN
« on: February 19, 2006, 07:15:39 AM »
Can someone do a walk through of how to VPN say two SME 7 servers together. Once thats done Id like to use port forwarding to connect to remote asterisk servers.

The purpose being running asterisk behind VPN.

Using OPENVPN
« Reply #1 on: March 05, 2006, 01:48:44 AM »
I have been looking for an easy way to do this as well.

I have been seeking to pay someone to create a panel to do this for me.

Any hired guns out there?

-Rick Evans

email: rick_NOatSPAM_theevansfamily.com
revans_NO at SPAM_optsvc.com
Seeeeeeeeeeeeeeee ya,
Rick :pint:

duncan

Using OPENVPN
« Reply #2 on: March 05, 2006, 06:08:26 AM »
Quote from: "rick1908"
I have been looking for an easy way to do this as well.


Cheap, easy, always up

achandra

Been working on it myself because I could find any help
« Reply #3 on: March 05, 2006, 09:41:01 AM »
rick1908 I think I have a solution for this. Ive been researching it through this forum and reading up.


Let assume you put up one in box in server mode and the other as a client then effectively they are "tunneled".

I think the Swerts-Knudsen instructions are suffiecient for running a server and he gives insight into the windows setup but its not that much more different for the linux client version. I think you need to simply pass a
--client flag. Im working on this now and Ill have the stats for you soon, once I export over the keys and cert.

CKConsulting

Using OPENVPN
« Reply #4 on: March 11, 2006, 02:47:31 AM »
Any Luck/Skill getting the SME7 to SME7 vpn working?  and stable?

Rick

Using OPENVPN
« Reply #5 on: March 11, 2006, 03:14:53 AM »
I am still struggling.
Seeeeeeeeeeeeeeee ya,
Rick :pint:

achandra

Okay lets think this through
« Reply #6 on: March 11, 2006, 06:41:19 AM »
Okay Swerts-Knudsen setup basically walks through a situation where :

1) a port is opened up to allow VPN connections to be made
2) Then it offers a bridged ip to the client and then allows connectivity to resources on your internal subnet.

Now lets think about a base setup of a fresh SME box...you have many choices persay of how to setup but you would NOT want to setup the client box in a (server gateway situation). It should likely be setup as a standalone.

Id think you'd setup the box with one static ip or the dhcp one you get from your isp. Next get a version of openvpn package, and install. pehaps even the one that Swerts-Knudsen has.

Lets then assume the following scenario - A "client/server" two SME server configuration.

So.....

1) Setup  the server/gateway sme server as youd like and install the Swerts packages ( do a search on contribs.org and you'll find it ). Install Openvpn and put it and put into "server mode" as described on the swerts website

2) Setup the second box in server mode only ( no internal gatewaying). The reason I say this is is to simplify the setup. Next install open-vpn on the second box but you'll treat it like windows box the swerts discusses. Import the certs on this box from the  other "server mode" box. Then put the box in client mode. It will acquire a bridged IP and allow you to connect to resources on the inside LAN of the "Server mode" lan.


Now for the big question how to use the NAT function on the Client mode server....then all internal clients on the client mode lan to connect to the server mode lan.

Id say work on step #2 and then think about and keep going....

Re: Using OPENVPN
« Reply #7 on: March 11, 2006, 06:55:27 PM »
Quote from: "achandra"
Can someone do a walk through of how to VPN say two SME 7 servers together. Once thats done Id like to use port forwarding to connect to remote asterisk servers.

The purpose being running asterisk behind VPN.


I'd say that using ipsec in this situation is more easy (depending on your knowledge though). Ipsec can be worrysome, but for two identical servers as endpoint for a tunnel where you want to tunnel internal networks it is ideal.
However, this has not been delved into a lot yet here.

See
http://www.hanscees.com/sme7/smecontribs.html
and then ipsec for a starter.

If you have never used ipsec before though this is probably not a good way to go.

Hans-Cees
nl.linkedin.com/in/hanscees/

CKConsulting

Using OPENVPN
« Reply #8 on: March 13, 2006, 11:42:14 PM »
achandra,

Thanks for your input, my network is layed out below.  With your suggestion, how would I use the box as a gateway for Site #2 if I have SME set to Server Only Mode?

Site 1:  Windows 2000 domain
            SME box as gateway running Dan's Guardian
            VPN server
            Static IP
            about 10 Win PC's XP
            Email server
            BackupPC

Site 2:  Remote location
            Static IP
            SME box as gateway running Dan's Guardian
            VPN client
            10 Win PC's XP
            BackupPC

Thanks
Rick

Using OPENVPN
« Reply #9 on: March 15, 2006, 10:37:20 PM »
I was wondering howto set up a server-to server tunnel to allow to remote networks to conect to echother.

I have searched openvpn.net and came up with the following. This has not been tested mind you, but should work.

Hans-Cees


http://openvpn.net/static.html

Openvpn traffic occurs over UDP port 1194, the default OpenVPN port.

Generate a static key:
    openvpn --genkey --secret static.key

Copy the static key to both client and server, over a pre-existing
secure channel.

#network/client ---client  ==udp 1194==  server -- network/server
#................tundevice ================tundevice  ---------------

#network/client 10.12.12.0/24 ---client 1.2.3.4 ==udp 1194== 2.3.4.5  server -- network/server 10.22.22.0/24
#................tundevice 10.4.0.1  ==============tundevice 10.4.0.2 ---------------


route a subnetwork from server to client
#on client route network to the other side's tun-ip
route add -net 10.22.22.0 netmask 255.255.255.0 gw 10.4.0.2

#on server route network to the other side's tun-ip
route add -net 10.12.12.0 netmask 255.255.255.0 gw 10.4.0.1


##Server configuration file
    dev tun
    ifconfig 10.4.0.2 10.4.0.1
    secret static.key
comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key

##Client configuration file
    remote myremote.mydomain
    dev tun
    ifconfig 10.4.0.1 10.4.0.2
    secret static.key
comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key



iptables rules:

#server:
#let openvpn traffic in and out
iptables -A INPUT -p udp -s 1.2.3.4 --dport 1194 -j ACCEPT
iptables -A OUTPUT -p udp -s 2.3.4.5 --sport 1194 -j ACCEPT

#traffic over the tunnel to the server itsself (only icmp for ping)
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -i tun+ -p icmp -j ACCEPT
#allow a network over the tun devices
iptables -A FORWARD -i tun+ -j ACCEPT

client:
#let openvpn traffic in and out
iptables -A INPUT -p udp -s 2.3.4.5 --sport 1194 -j ACCEPT
iptables -A OUTPUT -p udp -s 1.2.3.4 --dport 1194 -j ACCEPT

#traffic over the tunnel to the server itsself (only icmp for ping)
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -i tun+ -p icmp -j ACCEPT
#allow a network over the tun devices
iptables -A FORWARD -i tun+ -j ACCEPT



If you have this working and you can ping from client to server and
back and from the networks please make sure you ditch the static
secret keys and use tls.
nl.linkedin.com/in/hanscees/

Using OPENVPN
« Reply #10 on: March 20, 2006, 10:34:33 PM »
my howto here:

http://hanscees.com/sme7/openvpnsitetositetunnelsme7.html

should help you.

Hans-Cees
nl.linkedin.com/in/hanscees/

Offline pcdoc

AHH!!!! frustration is setting in with my open vpn setup
« Reply #11 on: March 31, 2006, 06:49:11 AM »
Right, after a fair amount of examination, it appears as if there is something strange going on with dns through the tunnel.

imagine the following scenario

Server A = www.srva.com = 192.168.3.0/24 - 192.168.3.222
Server B = www.srvb.com = 192.168.5.0/24 - 192.168.5.222

if a client 192.168.3.15 on server A side pings an ip address 192.168.5.220 on server B

ServerA-eth0 shows request going from 192.168.3.15 to 192.168.5.220
ServerA-tun0 shows request going from 192.168.3.15 to 192.168.5.220
ServerB-tun0 shows request going from 192.168.3.15 to pc-00220.srvb.com
ServerB-eth0 shows nothing because there is no pc-00220.srvb.com

if a client 192.168.5.220 on server B side pings an ip address 192.168.3.15 on server A

ServerB-eth0 shows request going from 192.168.5.220 to 192.168.3.15
ServerB-tun0 shows request going from 192.168.5.220 to 192.168.3.15
ServerA-tun0 shows request going from 192.168.5.220 to pc-00015.srva.com
ServerA-eth0 shows nothing because there is no pc-00015.srva.com


It appears to be a DNS problem from tunneling. I dont really know where to look from here, any pointers would be appreciated.

my server.conf file is

###########server.conf##################
# server.conf see http://openvpn.net/howto.html
# either use remote, or use mode server
## remote
remote XX.XX.XX.XXX
ifconfig 192.168.0.1 192.168.0.2

proto udp
port 1194
#optional what address to listen to
#local 213.4.3.1
dev tun
tls-server
dh dh1024.pem
ca ca.crt
cert server.crt
key server.key #should be kept secret
#secret static.key #you could do without certificates, please don't
comp-lzo # Enable compression on the VPN link.
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem
up ./openvpn.up
persist-tun
persist-key
status-version 2
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 5
#client-to-client
#########################################

my server openvpn.up script

###########################
#!/bin/sh

#on server route network to the other side's tun-ip
#you should add this route in sme7 server-manager or it will dissappear
route add -net 192.168.60.0 netmask 255.255.255.0 gw 192.168.0.1
#let openvpn traffic in and out (not needed on sme due to service)
#iptables -A INPUT -p udp -s 1.2.3.4 --dport 1194 -j ACCEPT
#iptables -A OUTPUT -p udp -s 2.3.4.5 --sport 1194 -j ACCEPT
#traffic over the tunnel to the server itsself (only icmp for ping)
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
#allow a network over the tun devices
iptables -A FORWARD -i tun+ -j ACCEPT
logger "openvpn is up"
######################################

my client.conf file is

###########client.conf##################
#client.conf
#remote 58.6.124.108 1194
##either use "ifconfig" or use "client". When remote uses "server",
#client should use "client"
##only use ifconfig if server also uses "remote".
ifconfig 192.168.0.2 192.168.0.1
#client

proto udp
dev tun
tls-client
#ns-cert-type server #todo in cert make step
#remote-cert-tls server
dh dh1024.pem
ca ca.crt
cert client.crt
key client.key
comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem
up ./openvpn.up
persist-tun
persist-key
status-version 2
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 6
#########################################

my client openvpn.up script is

###########################
#!/bin/sh
#on client route network to the other side's tun-ip
#you should add this route in severmanager as well or it will dissappear on sme7
route add -net 192.168.59.0 netmask 255.255.255.0 gw 192.168.0.2
#let openvpn traffic in and out
iptables -A INPUT -p udp --sport 1194 -j ACCEPT
iptables -A OUTPUT -p udp --dport 1194 -j ACCEPT
#traffic over the tunnel to the server itsself (only icmp for ping)
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
#allow a network over the tun devices
iptables -A FORWARD -i tun+ -j ACCEPT
logger "openvpn is up"
######################################

I am really starting to pull my hair out over this one, and starting to thing about investing some time with ipsec.... or at the pub.... or both!!
There are 10 types of people in this world,
   Those that know binary, and those who don't!

Re: AHH!!!! frustration is setting in with my open vpn setup
« Reply #12 on: April 03, 2006, 08:04:51 PM »
Quote from: "pcdoc"
Right, after a fair amount of examination, it appears as if there is something strange going on with dns through the tunnel.

imagine the following scenario

Server A = www.srva.com = 192.168.3.0/24 - 192.168.3.222
Server B = www.srvb.com = 192.168.5.0/24 - 192.168.5.222

if a client 192.168.3.15 on server A side pings an ip address 192.168.5.220 on server B

ServerA-eth0 shows request going from 192.168.3.15 to 192.168.5.220
ServerA-tun0 shows request going from 192.168.3.15 to 192.168.5.220
ServerB-tun0 shows request going from 192.168.3.15 to pc-00220.srvb.com
ServerB-eth0 shows nothing because there is no pc-00220.srvb.com

if a client 192.168.5.220 on server B side pings an ip address 192.168.3.15 on server A

ServerB-eth0 shows request going from 192.168.5.220 to 192.168.3.15
ServerB-tun0 shows request going from 192.168.5.220 to 192.168.3.15
ServerA-tun0 shows request going from 192.168.5.220 to pc-00015.srva.com
ServerA-eth0 shows nothing because there is no pc-00015.srva.com


It appears to be a DNS problem from tunneling. I dont really know where to look from here, any pointers would be appreciated.

#you should add this route in sme7 server-manager or it will dissappear
route add -net 192.168.60.0 netmask 255.255.255.0 gw 192.168.0.1

###########client.conf##################
route add -net 192.168.59.0 netmask 255.255.255.0 gw 192.168.0.2
#let openvpn traffic in and out


Hi,
I think your routing is wrong.

On server a it should be:
route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.0.2
The network you are adding a route for lives acros the tunnel and the gateway is the ppp-ip on the other side of the tunnel.

on b:
route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.0.1

With the routing you posted I do not understand how the packages even get across the tunnel really.

About the apparant dns problems, I think that is an artefact of how look at the tcpdumps. If you use tcpdump user tcpdump -nlpi eth0. The -n makes sure you do not back-resolve ip-numers. In ethereal there is also such a feature under options.

You did not post the internal ip-addresses of the servers. You might have a routing problem there also.

Hans-Cees
nl.linkedin.com/in/hanscees/

Offline pcdoc

Using OPENVPN
« Reply #13 on: April 04, 2006, 04:24:36 AM »
server a internal ip range is 192.168.59.0 and
server b internal ip range is 192.168.60.0.

sorry i forgot to mention that :(

should the routes still be changed??
There are 10 types of people in this world,
   Those that know binary, and those who don't!

Offline pcdoc

Using OPENVPN
« Reply #14 on: April 04, 2006, 04:30:40 AM »
maybe more information is required as well.

server a > > router > > internet > > router > > server b
192.168.59.222 / 192.168.5.3 > > 192.168.5.1 / xx.xx.xx.xx > > xx.xx.xx.xx / 192.168.3.1 > > 192.168.3.20 / 192.168.60.222

tunnel should be
192.168.59.222 / 192.168.0.1 > > 192.168.0.2 / 192.168.60.222

does this make the previous post make more sense??
There are 10 types of people in this world,
   Those that know binary, and those who don't!

Using OPENVPN
« Reply #15 on: April 05, 2006, 12:00:06 AM »
Quote from: "pcdoc"
maybe more information is required as well.

server a > > router > > internet > > router > > server b
192.168.59.222 / 192.168.5.3 > > 192.168.5.1 / xx.xx.xx.xx > > xx.xx.xx.xx / 192.168.3.1 > > 192.168.3.20 / 192.168.60.222

tunnel should be
192.168.59.222 / 192.168.0.1 > > 192.168.0.2 / 192.168.60.222

does this make the previous post make more sense??


You need to have two routes across the tunnel then. For the 192.168.5.0/24 and the 192.168.69.0/24. Both to the 192.168.0.2 gateway acrosse the tunnel.
nl.linkedin.com/in/hanscees/

jaydub

Unable to connect to machines behind openvpn server
« Reply #16 on: April 06, 2006, 07:11:38 PM »
I followed the sme7 tutorial for linking two sme7 servers with openvpn as told here: http://hanscees.com/sme7/openvpnsitetositetunnelsme7.html

I am able to ping from either the sme gateway/openvpn server to the client and vice versa. I am unable to ping from any machines on the server's internal network to machines on the client's internal network. Same holds for the reverse.

Conf files are:

server.conf

remote 219.142.220.16
ifconfig 10.4.0.1 10.4.0.2

proto udp
port 1194

dev tun
tls-server
dh dh1024.pem
ca ca.crt
cert server.crt
key server.key

comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem

up ./openvpn.up

persist-tun
persist-key
status-version 2
status /var/log/openvpn/openvpn-status.log
verb 3

openvpn.up (server side)

route add -net 192.168.4.0 netmask 255.255.255.0 gw 10.4.0.2
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT


client.conf

remote 219.142.219.48 1194
ifconfig 10.4.0.2 10.4.0.1

proto udp
dev tun
tls-client
dh dh1024.pem
ca ca.crt
cert client.crt
key client.key
comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem

up ./openvpn.up

persist-tun
persist-key
status-version 2
status /var/log/openvpn/openvpn-status.log
verb 3

openvpn.up (client side)

route add -net 192.168.3.0 netmask 255.255.255.0 gw 10.4.0.1

iptables -A INPUT -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -p udp --sport 1194 -j ACCEPT
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT


Both client and server can ping the remote gateway both eth0 and tun0 addresses. But any clients whether windows or linux on either side cannot ping other machines across the vpn.

specifically we are looking to allow machines on the client network to be able to access one machine on the server network via SMB.

any advice on where to start looking? We suspect it may be due to the iptables rules in sme7rc1 but are not really sure where to look.

-Jeff

Re: Unable to connect to machines behind openvpn server
« Reply #17 on: April 06, 2006, 11:21:16 PM »
Quote from: "jaydub"
I followed the sme7 tutorial for linking two sme7 servers with openvpn as told here: http://hanscees.com/sme7/openvpnsitetositetunnelsme7.html

I am able to ping from either the sme gateway/openvpn server to the client and vice versa. I am unable to ping from any machines on the server's internal network to machines on the client's internal network. Same holds for the reverse.

Conf files are:

server.conf

remote 219.142.220.16
ifconfig 10.4.0.1 10.4.0.2

proto udp
port 1194

dev tun
tls-server
dh dh1024.pem
ca ca.crt
cert server.crt
key server.key

comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem

up ./openvpn.up

persist-tun
persist-key
status-version 2
status /var/log/openvpn/openvpn-status.log
verb 3

openvpn.up (server side)

route add -net 192.168.4.0 netmask 255.255.255.0 gw 10.4.0.2
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT


client.conf

remote 219.142.219.48 1194
ifconfig 10.4.0.2 10.4.0.1

proto udp
dev tun
tls-client
dh dh1024.pem
ca ca.crt
cert client.crt
key client.key
comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem

up ./openvpn.up

persist-tun
persist-key
status-version 2
status /var/log/openvpn/openvpn-status.log
verb 3

openvpn.up (client side)

route add -net 192.168.3.0 netmask 255.255.255.0 gw 10.4.0.1

iptables -A INPUT -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -p udp --sport 1194 -j ACCEPT
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT


Both client and server can ping the remote gateway both eth0 and tun0 addresses. But any clients whether windows or linux on either side cannot ping other machines across the vpn.

specifically we are looking to allow machines on the client network to be able to access one machine on the server network via SMB.

any advice on where to start looking? We suspect it may be due to the iptables rules in sme7rc1 but are not really sure where to look.

-Jeff


Hi,

could you check if the routing is ok on both servers when the tunnel is up:
netstat -r
and post that back?

Can you post the outcome of
tcpdump -nlpi insideinterface
of server A when you ping from the network behind server B?
nl.linkedin.com/in/hanscees/

jaydub

Using OPENVPN
« Reply #18 on: April 12, 2006, 02:25:37 PM »
Quote

Hi,

could you check if the routing is ok on both servers when the tunnel is up:
netstat -r
and post that back?

Can you post the outcome of
tcpdump -nlpi insideinterface
of server A when you ping from the network behind server B?


Server A (Server) Routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.4.0     10.4.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.4.0.0        192.168.3.1     255.255.255.0   UG    0      0        0 eth0
219.142.216.0   0.0.0.0         255.255.248.0   U     0      0        0 eth1
0.0.0.0         219.142.216.1   0.0.0.0         UG    0      0        0 eth1

Server B (Client) Routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.3.0     10.4.0.1        255.255.255.0   UG    0      0        0 tun0
10.4.0.0        192.168.4.1     255.255.255.0   UG    0      0        0 eth0
219.142.216.0   0.0.0.0         255.255.248.0   U     0      0        0 eth1
0.0.0.0         219.142.216.1   0.0.0.0         UG    0      0        0 eth1

If I run tcpdump on the server's internal interface ( I am assuming
the tunneling interface tun0 as there is no traffic visible on eth0
from the client network) I can see the attempts at pinging or trying to view SMB shares:

20:22:05.893588 IP 192.168.4.204.38714 > 192.168.3.2.microsoft-ds: S 1780914548:1780914548(0) win 5840 <mss 1366,sackOK,timestamp 29016041 0,nop,wscale 2>
20:22:16.459340 IP 192.168.4.204 > 192.168.3.2: icmp 64: echo request seq 1
20:22:17.459759 IP 192.168.4.204 > 192.168.3.2: icmp 64: echo request seq 2

etc...

ok so where do I go from here?

Using OPENVPN
« Reply #19 on: April 12, 2006, 07:42:44 PM »
Quote from: "jaydub"
Quote

Can you post the outcome of
tcpdump -nlpi insideinterface
of server A when you ping from the network behind server B?


Server A (Server) Routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.4.0     10.4.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.4.0.0        192.168.3.1     255.255.255.0   UG    0      0        0 eth0
219.142.216.0   0.0.0.0         255.255.248.0   U     0      0        0 eth1
0.0.0.0         219.142.216.1   0.0.0.0         UG    0      0        0 eth1

Server B (Client) Routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.3.0     10.4.0.1        255.255.255.0   UG    0      0        0 tun0
10.4.0.0        192.168.4.1     255.255.255.0   UG    0      0        0 eth0
219.142.216.0   0.0.0.0         255.255.248.0   U     0      0        0 eth1
0.0.0.0         219.142.216.1   0.0.0.0         UG    0      0        0 eth1

If I run tcpdump on the server's internal interface ( I am assuming
the tunneling interface tun0 as there is no traffic visible on eth0
from the client network) I can see the attempts at pinging or trying to view SMB shares:

20:22:05.893588 IP 192.168.4.204.38714 > 192.168.3.2.microsoft-ds: S 1780914548:1780914548(0) win 5840 <mss 1366,sackOK,timestamp 29016041 0,nop,wscale 2>
20:22:16.459340 IP 192.168.4.204 > 192.168.3.2: icmp 64: echo request seq 1
20:22:17.459759 IP 192.168.4.204 > 192.168.3.2: icmp 64: echo request seq 2

etc...

ok so where do I go from here?


Lets see if I got this right.
You ping from host 192.168.4.204 to 192.168.3.2.

192.168.4.204 is behind server b.
traffic arives at eth0 of server b. It is then routed into the tunnel, because of the route on server B:
192.168.3.0     10.4.0.1        255.255.255.0   UG    0      0        0 tun0

It then arives at tun0 at server a.
It should then go to eth0 becuase of route on ser er a:
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

But if you tcpdump on eth0 you see no traffic.

This very likely mean there is some iptables rule in the way.

Can you try on server A:
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT

and see if you now see traffic when tcpdumping eth0?
tcpdump -nlpi eth0

If that does not work we can also try:

iptables -A INPUT -i eth0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -o eth0 -j ACCEPT

please let me know what, if anything, works.
nl.linkedin.com/in/hanscees/