Re: [Openvpn-users] Site2Site - routing-problem (linux)

[Martin Müller - Rudolf Hausstein OHG <m.mueller@xxxxxxxxxxxx>]

Phil Burrow schrieb:
> Martin Müller - Rudolf Hausstein OHG wrote:
>
> > So I changed my second LAN to your suggestion. But it wasnt working 
> > (like 10.8.0.0). Cant reach the Server-LAN from the Client-Lan.
> >
> > So what I think is, that the problem belongs to the networkmask.
> > I changed my Client-LAN to 192.168.200.0
> >
> > #/etc/openvpn/server.conf
> > route 192.168.200.0 255.255.255.0
> > push "route 192.168.100.0 255.255.255.0"
> > Here again, I put away the line
> >    'push "route 192.168.200.0 255.255.255.0" '
> > because when I use this, the Clients of 192.168.200.0/24 cant reach 
> > 192.168.200.99.
>
> Maybe this is because you are using redirect-gateway. I have that push 
> route line in my own server.conf and I have no problems but you seem 
> to get an extra route in your client routing table that I don't get. 
> Strange. :)
>
> > route in the client with tun0 up:
> > Ziel            Router          Genmask         Flags Metric Ref    
> > Use Iface
> > 192.168.100.0   192.168.123.5   255.255.255.0   UG    0      0        
> > 0 tun0
> > 192.168.200.0   192.168.123.5   255.255.255.0   UG    0      0        
> > 0 tun0
> > 192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        
> > 0 eth0
>
> ^^^^^^^^^^^^^^^
>
> > 192.168.123.0   192.168.123.5   255.255.255.0   UG    0      0        
> > 0 tun0
>
> Again you have two routes for 192.168.200.0 - one sending it down eth0 
> and one down tun0. If you removed the push "route 192.168.200.0 
> 255.255.255.0" line, I am not sure why you are getting this.
>
> Try disabling push "redirect-gateway" first of all and test pings etc 
> to see if it works.
I had disabled redirect. No effect, but the doubleentry 192.168.200.0 is 
gone.

Client:~# route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use 
Iface
192.168.123.5   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
83.64.124.96    0.0.0.0         255.255.255.240 U     0      0        0 eth1
192.168.100.0   192.168.123.5   255.255.255.0   UG    0      0        0 tun0
192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.123.0   192.168.123.5   255.255.255.0   UG    0      0        0 tun0
0.0.0.0         83.64.124.97    0.0.0.0         UG    0      0        0 eth1


When I restart the server, something like this is to read in openvpn.log:

/sbin/ifconfig tun0 192.168.123.1 pointopoint 192.168.123.2 mtu 1500
/sbin/route add -net 192.168.200.0 netmask 255.255.255.0 gw 192.168.123.2
sbin/route add -net 192.168.123.0 netmask 255.255.255.0 gw 192.168.123.2
IFCONFIG POOL: base=192.168.123.4 size=62
IFCONFIG POOL LIST
TEST,192.168.123.4
Initialization Sequence Completed


When I connect with the client, I get:

Peer Connection Initiated with 83.64.124.105:32775
TEST/83.64.124.105:32775 MULTI: Learn: 192.168.123.6 -> 
TEST/83.64.124.105:32775
TEST/83.64.124.105:32775 MULTI: primary virtual IP for 
TEST/83.64.124.105:32775: 192.168.123.6
TEST/83.64.124.105:32775 PUSH: Received control message: 'PUSH_REQUEST'
TEST/83.64.124.105:32775 SENT CONTROL [TEST]: 'PUSH_REPLY,route 
192.168.100.0 255.255.255.0,route 192.168.123.0 255.255.255.0,ping 
15,ping-restart 145,ifconfig 192.168.123.6 192.168.123.5' (status=1)

maybe this help us by finding the solution


> Next..
>
> Have you tried sniffing the tun0 interface to see what's happening?
>
> Do a ping on your client like:
>
> ping 192.168.100.1 -I 192.168.200.1
>
> (Change the IP's if the ones I used are wrong. The first one should be 
> any machine on your server LAN and the second one should be the local 
> IP on your client gateway. This makes it looks like the ping came from 
> your client LAN.)
>
> Log on your server and use tcpdump -i tun0 or ethereal if you have it 
> to see if the pings are coming through. If you use the IP's above, you 
> should see something like:
>
> 11:18:29.793920 IP 192.168.200.1 > 192.168.100.1: icmp 64: echo 
> request seq 3
> 11:18:29.794440 IP 192.168.100.1 > 192.168.200.1: icmp 64: echo reply 
> seq 3 

Ok, now I have tried on the client to ping 192.168.100.190 -I 
192.168.200.99  (.99 ist the VPN-Client). This doenst work, in 
openvpn.log appears

TEST/83.64.124.105:32770 MULTI: bad source address from client 
[192.168.200.99], packet dropped

tcdump is dumb during this ping.


If I try to ping 192.168.100.190 tcdump says

13:35:46.632014 IP 192.168.100.190 > 192.168.123.6: ICMP echo reply, id 
10252, seq 4, length 64
openvpn.log is dumb


If I try to ping 192.168.100.190 -I 192.168.200.100 (.100 is a machine 
behind the VPNClient), I get the ping-error

bind: Cannot assign requested address


I think its hard to find the solution here. Is it necessary to activate 
masquering on the VPN-Client?


Best regards,

Martin







-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users