|
|
Erich, Originally, my ccd file was iroute 172.27.255.240 255.255.255.240 ifconfig-push 172.28.128.11 172.28.128.1 I had forgotten about the /30 subnets (I don't really need them; I should probably enable the ifconfig-pool-linear option as I'll only have Linux clients.) But in the interests of being thorough, I just changed it to this: iroute 172.27.255.240 255.255.255.240 ifconfig-push 172.28.128.9 172.28.128.10 Now my route on the client is: 172.28.128.10 dev tun0 proto kernel scope link src 172.28.128.9 172.28.128.1 via 172.28.128.10 dev tun0 172.27.255.240/28 dev eth1 proto kernel scope link src 172.27.255.241 192.168.96.0/24 dev eth0 proto kernel scope link src 192.168.96.99 169.254.0.0/16 dev eth1 scope link default via 192.168.96.1 dev eth0 and adding the incriminating route adds 192.168.1.0/24 via 172.28.128.10 dev tun0 but i still see the same behavior. As a further clue, after dropping the offending route, after the starting the ping again, there is the wait of about 5-6 seconds before the initial packets return. Before that burst of packets, on the server I see the following errors: RWed Jun 28 09:52:48 2006 us=531401 OpenVPN_Client_Test_County_01/192.168.1.162:34035 MULTI: bad source address from client [192.168.96.99], packet dropped RWed Jun 28 09:52:48 2006 us=531552 OpenVPN_Client_Test_County_01/192.168.1.162:34035 MULTI: bad source address from client [192.168.96.99], packet dropped RWed Jun 28 09:52:48 2006 us=531659 OpenVPN_Client_Test_County_01/192.168.1.162:34035 MULTI: bad source address from client [192.168.96.99], packet dropped RwRWed Jun 28 09:52:48 2006 us=531848 OpenVPN_Client_Test_County_01/192.168.1.162:34035 MULTI: bad source address from client [192.168.96.99], packet dropped RwRWed Jun 28 09:52:48 2006 us=532075 OpenVPN_Client_Test_County_01/192.168.1.162:34035 MULTI: bad source address from client [192.168.96.99], packet dropped RwRwRWed Jun 28 09:52:48 2006 us=532426 OpenVPN_Client_Test_County_01/192.168.1.162:34035 MULTI: bad source address from client [192.168.96.99], packet dropped RwRwRWed Jun 28 09:52:48 2006 us=532686 OpenVPN_Client_Test_County_01/192.168.1.162:34035 MULTI: bad source address from client [192.168.96.99], packet dropped So I don't know why the NAT address of 192.168.96.99 is getting sent over the VPN link. Thanks. Moshe Erich Titl wrote: > I don't know how you assigned ip addresses to your tun interface. An > address of 172.28.128.11 looks suspicious as it is the broadcast address > of the 172.28.128.8/30 subnet. Seeing that you use ccd-exclusive I > assume that you assign the tunnel addresses using a ccd file. That is > where you probably flunked. > > my ccd file for the data below loks like > > ifconfig-push 10.111.1.17 10.111.1.18 > > Here is the client tunnel in one of my systems > > 50: tun1: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast > qlen 100 link/ppp inet 10.111.1.17 peer 10.111.1.18/32 scope global tun1 > > the corresponding routing looks like > > # ip route > 10.111.1.1 via 10.111.1.18 dev tun1 > 10.111.1.18 dev tun1 proto kernel scope link src 10.111.1.17 > 10.111.2.2 dev tun0 proto kernel scope link src 10.111.2.1 > 10.111.2.0/24 via 10.111.2.2 dev tun0 > 192.168.2.0/24 dev ath0 proto kernel scope link src 192.168.2.1 > 194.124.158.0/24 via 10.111.1.18 dev tun1 > 84.73.176.0/22 dev eth0 proto kernel scope link src 84.73.179.80 > default via 84.73.176.1 dev eth0 > > As you can see, the server having address 10.111.1.1 is routed through > 10.111.18 using tun1. The 194.124.158.0/24 subnet behind the server is > also routed through 10.111.1.18 > > cheers > > Erich > > -- ---- Moshe Hyzon Grant Street Group Ph: 412-391-5555, ext. 344 ______________________ OpenVPN mailing lists https://lists.sourceforge.net/lists/listinfo/openvpn-users |