I can only ping one way. Client to server works.

jcavil · Post by **jcavil** » Sat Nov 20, 2010 12:56 am

I have read and understand the routing section, As far as I can tell my network is setup according to those guidelines. I hope you can be patient with me as I'm not the type who normally asks for help, but after struggling with this for two weeks I don't know where else to turn or what else to google (Also using your seach hasn't helped as I can't search for common terms like "Routing one way" though I don't know what else to call my problem.

Sorry If I give you too much information, but I don't want to miss something that may be key.

Two networks (full networks with multiple computers on both sides)

ClearOS/openVPN acting as server: 192.168.0.x
Tomato (Linux router distro) with openVPN acting as client 192.168.6.x

I have openVPN working great one way, on the Client side (.6.x) I can reach all network resources on the serer side. (Remote Desktop, Ping, Internal websites, file shares, clearos config panel, etc)

On the Server side (.0.x) I can't reach anything on the client side, can't ping anything, tracert anything, reach network resources, web config panels etc)

Code: Select all

port 1194
proto udp
dev tun
ca /etc/ssl/ca-cert.pem
cert /etc/ssl/sys-0-cert.pem
key /etc/ssl/private/sys-0-key.pem
dh /etc/ssl/dh1024.pem
server 10.8.0.0 255.255.255.0
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
ifconfig-pool-persist /var/lib/openvpn/ipp.txt
status /var/lib/openvpn/openvpn-status.log
verb 3
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-ldap.so /etc/openvpn/auth-ldap
push "dhcp-option DNS 192.168.0.1"
push "dhcp-option WINS 192.168.0.1"
push "dhcp-option DOMAIN broadway.duboisfw.com"
client-config-dir ccd
route 192.168.6.0 255.255.255.0
push "route 192.168.0.0 255.255.255.0"

In the client config dir ccd I have a text file named the login name with the single line

iroute 192.168.6.0. 255.255.255.0

On the client side I have

Code: Select all

comp-lzo
verb 3
proto udp
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
auth-user-pass /root/pass
push "route 192.168.6.0 255.255.255.0"
route 192.168.6.0 255.255.255.0

(And other stuff is configured automatically through the GUI)

Here is the log output for the server side.

Code: Select all

Nov 19 17:28:08 broadway openvpn[12330]: ROUTING TABLE
Nov 19 17:28:08 broadway openvpn[12330]: Virtual Address,Common Name,Real Address,Last Ref
Nov 19 17:28:08 broadway openvpn[12330]: 10.8.0.6,store06,69.21.142.2:1027,Fri Nov 19 17:28:05 2010
Nov 19 17:28:08 broadway openvpn[12330]: 192.168.6.0/24,store06,69.21.142.2:1027,Fri Nov 19 16:57:05 2010

Here is the log output one the server when the client connects

Code: Select all

Nov 19 16:57:05 broadway openvpn[12330]: MULTI: Learn: 10.8.0.6 -> store06/##.##.142.2:1027
Nov 19 16:57:05 broadway openvpn[12330]: MULTI: primary virtual IP for store06/##.##.142.2:1027: 10.8.0.6
Nov 19 16:57:05 broadway openvpn[12330]: MULTI: internal route 192.168.6.0/24 -> store06/##.##.142.2:1027
Nov 19 16:57:05 broadway openvpn[12330]: MULTI: Learn: 192.168.6.0/24 -> store06/##.##.142.2:1027
Nov 19 16:57:05 broadway openvpn[12330]: REMOVE PUSH ROUTE: 'route 192.168.6.0 255.255.255.0'
Nov 19 16:57:07 broadway openvpn[12330]: store06/##.##.142.2:1027 PUSH: Received control message: 'PUSH_REQUEST'
Nov 19 16:57:07 broadway openvpn[12330]: store06/69.21.142.2:1027 SENT CONTROL [store06]: 'PUSH_REPLY,dhcp-option DNS 192.168.0.1,dhcp-option WINS 192.168.0.1,dhcp-option DOMAIN broadway.duboisfw.com,route 192.168.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)
Nov

What is that remove push route line, could that cause a problem?

On the client side here are some routing details.

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun11
/Client's external IP   h##-##-142-1.ap 255.255.255.255 UGH   0      0        0 vlan1
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun11
##.##.142.1     *               255.255.255.255 UH    0      0        0 vlan1
##.##.142.0     *               255.255.255.252 U     0      0        0 vlan1
192.168.6.0     *               255.255.255.0   U     0      0        0 br0
192.168.0.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun11
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         10.8.0.5        128.0.0.0       UG    0      0        0 tun11
128.0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun11
default         h##-##-142-1.ap 0.0.0.0         UG    0      0        0 vlan1

This looks great to me and makes a lot of sense.

On the ClearOS Server side I have this...

Code: Select all

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
Clients ext gateway   *               255.255.255.248 U     0      0        0 eth2
192.168.2.0     *               255.255.255.0   U     0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth1
default         hmyexternalip. 0.0.0.0         UG    0      0        0 eth2

This doesn't seem as good, it looks like it has no protocol for routing the 192.168.6.0 network over the vlan, am I right? (I don't know where 192.168.2.0 came from either)

Any ideas? I have been googling this problem for days now and I am stumped. I would love some help, It may be ClearOS's fault but nobody there is very helpful, I would greatly appreciate being pointed in the right direction, at this point I don't even know what is to blame, what I have to fix, or what keywords to google anymore.

(I will include the input and output of the clearos iptable chain as well just to be safe, if you need any more information for clarity please ask)

Code: Select all

Chain INPUT (policy DROP 28023 packets, 1352K bytes)
 pkts bytes target     prot opt in     out     source               destination
 5378  238K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x12/0x12 state NEW reject-with tcp-reset
  361  403K DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW
    0     0 DROP       all  --  eth2   *       127.0.0.0/8          0.0.0.0/0
    0     0 DROP       all  --  eth2   *       169.254.0.0/16       0.0.0.0/0
7764K 4907M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  pptp+  *       0.0.0.0/0            0.0.0.0/0
 2864  213K ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0
3262K  326M ACCEPT     all  --  eth1   *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            255.255.255.255     udp spt:68 dpt:67
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            255.255.255.255     tcp spt:68 dpt:67
    0     0 ACCEPT     udp  --  eth0   *       192.168.2.0/24       192.168.2.1         udp dpt:53
    0     0 ACCEPT     tcp  --  eth0   *       192.168.2.0/24       192.168.2.1         tcp dpt:53
    0     0 ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 0
    0     0 ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 3
    0     0 ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 8
    0     0 ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 11
 8677  252K ACCEPT     icmp --  eth2   *       0.0.0.0/0            0.0.0.0/0           icmp type 0
   26  8392 ACCEPT     icmp --  eth2   *       0.0.0.0/0            0.0.0.0/0           icmp type 3
  107  5993 ACCEPT     icmp --  eth2   *       0.0.0.0/0            0.0.0.0/0           icmp type 8
   56  4736 ACCEPT     icmp --  eth2   *       0.0.0.0/0            0.0.0.0/0           icmp type 11
    0     0 ACCEPT     udp  --  eth2   *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68
    0     0 ACCEPT     tcp  --  eth2   *       0.0.0.0/0            0.0.0.0/0           tcp spt:67 dpt:68
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            192.168.2.1         udp dpt:1194
1314K  164M ACCEPT     udp  --  *      *       0.0.0.0/0            Clientexternalip       udp dpt:1194
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.2.1         tcp dpt:4241
 1077 79304 ACCEPT     tcp  --  *      *       0.0.0.0/0            Clientexternalip6       tcp dpt:4241
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.2.1         tcp dpt:1875
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0           Clientexternalip       tcp dpt:1875
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpts:1024:65535 state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1024:65535 state RELATED,ESTABLISHED
  388 31936 ACCEPT     udp  --  eth2   *       0.0.0.0/0            0.0.0.0/0           udp dpts:1024:65535 state RELATED,ESTABLISHED
3337K 4228M ACCEPT     tcp  --  eth2   *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1024:65535 state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080

Code: Select all

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
7765K 4907M ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      pptp+   0.0.0.0/0            0.0.0.0/0
 2864 1174K ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0
4110K 4282M ACCEPT     all  --  *      eth1    0.0.0.0/0            0.0.0.0/0
10053  366K ACCEPT     icmp --  *      eth2    0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     udp  --  *      eth2    0.0.0.0/0            0.0.0.0/0           udp spt:68 dpt:67
    0     0 ACCEPT     tcp  --  *      eth2    0.0.0.0/0            0.0.0.0/0           tcp spt:68 dpt:67
    0     0 ACCEPT     udp  --  *      eth0    192.168.2.1          0.0.0.0/0           udp spt:1194
1073K  441M ACCEPT     udp  --  *      eth2    Clientexternalip        0.0.0.0/0           udp spt:1194
    0     0 ACCEPT     tcp  --  *      eth0    192.168.2.1          0.0.0.0/0           tcp spt:4241
  795  257K ACCEPT     tcp  --  *      eth2    Clientexternalip        0.0.0.0/0           tcp spt:4241
    0     0 ACCEPT     tcp  --  *      eth0    192.168.2.1          0.0.0.0/0           tcp spt:1875
    0     0 ACCEPT     tcp  --  *      eth2    Clientexternalip        0.0.0.0/0           tcp spt:1875
    0     0 ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
2992K  360M ACCEPT     all  --  *      eth2    0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0           tcp spt:8080

(I redacted my IP and added some #s where I think there was revealing info, if it affects something let me know or if you need clarification)

Client to Server Tracert

Code: Select all

Tracing route to 192.168.0.11 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  unknown [192.168.6.1]
  2    13 ms    12 ms    12 ms  10.8.0.1
  3    13 ms    13 ms    13 ms  192.168.0.11

Trace complete.

Server to Client

Code: Select all

Tracing route to 192.168.6.118 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     1 ms    <1 ms    <1 ms  My Client IP gateway.dedicated.static.tds.net [
My Client IP Gateway]
  3     *        *        *     Request timed out.

4 * *

Sorry for the TMI, But I figured it can't hurt.

Hopefully I'm stupid and forgot something obvious, I really hope thats the case. If you need any more information, log files after toggling a connection, anything like that, just ask. I know you aren't here to fix my problems directly, but I really need to be pointed in a direction as I don't know what else to read. I read the whole man file out of desperation

This was very helpfull too http://www.secure-computing.net/wiki/in ... PN/Routing as I did miss that, but now it looks like I have that correctly according to it.

Post by **krzee** » Sat Nov 20, 2010 1:09 am

your client is a router for its lan, so you got to skip a step on that side
did you add routes on the server's default gateway telling it how to route the lan's traffic to 10.8.0.0 255.255.255.0 and 192.168.6.0 255.255.255.0?
in the secure-computing link you posted, see the section named ROUTES TO ADD OUTSIDE OPENVPN

jcavil · Post by **jcavil** » Mon Nov 22, 2010 8:41 pm

Both sides client and server VPN are running on the routers/gateways for their networks.

ClearOS is an endpoint security/router/firewall/openvpn/all in one box (Based on the old ClarkOS and feature similar to Smoothwall and the other suites like that)

jcavil · Post by **jcavil** » Mon Nov 22, 2010 9:58 pm

Maybe could someone post (or point me to) a working lan to lan openvpn routing table / iptables

Maybe if I could look at a working config I could figure out where mine is dropping the packets on the way from the server to the client and add the rule myself.

secesh · Post by **secesh** » Tue Nov 23, 2010 3:32 am

Similar setup. got a little further, but still broke down.

SERVER: 192.168.24.202 (clearOS/openVPN server).
openVPN tun subnet 10.8.0.0/24
CLIENT: 10.1.1.1 (clearOS/client).

SERVER can ping client both on 10.8.0.x and 10.1.1.1. SERVER can further ping other clients in the 10.1.1.x subnet.
CLIENT can ping SERVER, and CLIENT can ping other hosts in the 192.168.24.x subnet.

Here's where I break down.
- other hosts in the CLIENT subnet (10.1.1.x) can NOT ping other hosts in the SERVER subnet, nor can they ping SERVER.
- other hosts in the SERVER subnet (192.168.24.x) can NOT ping other hosts in the CLIENT subnet.

using tcpdump, I've pinpointed this as loosing packets between 192.168.24.202 and 10.8.0.1 on the server. But I don't know why. I assume this is a security setting of openVPN that I've overlooked, and hope someone can point out my ignorance!

I have client-to-client in my server config.

thanks!

Santron55637 · Post by **Santron55637** » Wed Nov 24, 2010 11:00 pm

jcavil,

I do see 1 thing.
On the ClearOS Server side I have this...

Code:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
Clients ext gateway * 255.255.255.248 U 0 0 0 eth2
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
default hmyexternalip. 0.0.0.0 UG 0 0 0 eth2

The 192.168.0.0 is set to go out eth1 should this be tun0?

Santron55637 · Post by **Santron55637** » Wed Nov 24, 2010 11:11 pm

secesh,

Have you pointed the client hosts to route the ping packets to the client computer?

Example 10.1.1.2 should be routing all packets going to 192.68.24.0 to 10.1.1.1

OpenVPN Support Forum

I can only ping one way. Client to server works.

I can only ping one way. Client to server works.

Re: I can only ping one way. Client to server works.

Re: I can only ping one way. Client to server works.

Re: I can only ping one way. Client to server works.

Re: I can only ping one way. Client to server works.

Re: I can only ping one way. Client to server works.

Re: I can only ping one way. Client to server works.