Hello to all.
A friend of mine has a VPN linking it’s home and office networks, but it can’t access it’s subnet at the office. Apparently, the packets don’t pass the OpenSuSe gateway.
It’s configuration is somewhat complex so I uploaded a schematics at http://www.maisqi.com/schematics.jpg.
From subnet 192.168.10.0/24 we can ping any computer on 192.168.1.0/24. From the other way around we can’t ping past the Linux Server (192.168.5.251). If we SSH it, we can ping the internal network (192.168.10.0/24), as expected.
As you can see in the schematics, the VPN is implemented by the routers, not by Linux itself. But, do I have to do something special on the server to pass the packets it receives from the VPN at 192.168.5.251 to the internal network (192.168.10.0/24)?
As a concrete example, I need computer 192.168.1.253 to ping the one at 192.168.10.250.
I believe You’ve got a routing problem. I wonder why You can ping the 192.168.1.0/24. Have You got ip forwarding enabled on the linux server ?
Can You post the output of
route -n
command from the linux server ?
Sorry for the delay. The routing table seems to be fine.
What is the output of this command on the linux router ?
cat /proc/sys/net/ipv4/ip_forward
Do You have a route for the 192.168.10.0/24 network configured on router A and router B ?
Do You have a route for 192.168.1.0/24 configured on router B ?
Hello glistwan. Thanks for responding.
/proc/sys/net/ipv4/ip_forward has “1” on it.
About you’re questions about the routers, I can send you some screenshots of the web interface but are you sure it will help?
After all, we can ping computers in both ends of the VPN. The packets just don’t seem to pass from the 192.168.1.0/24 to the 192.168.10.0/24 subnet, but hit 192.168.1.250 (the openSUSE server).
Thanks for your help and please confirm that you need the routers’ Web Interface screenshots.
Actually after thinking about this I think I’ve got a better idea now. As the ping passes from one side to another all routing must be in place as it’s bidirectional communication. You send the packets but the devices You ping have to send the reply back to You. So my advice is to try and turn off the firewall on the linux server for a while or turn on logging dropped packets with firewall still turned on and see what gets dropped (for a safer diagnostics method). The logs are I think in the file /var/log/firewall but I’m not sure as I’m writing this from a pure Windows machine. This command might be helpful to observe the log file ‘live’ :
sudo tail -f /var/log/firewall
Once You know it’s the firewall You have to open all the ports You will be using on the VPN, which IMHO is done easiest using YAST.
Hello again.
I tried what you suggested with no luck. I tried pinging 192.168.1.250 (the Linux server) from 192.168.1.253, but got no entry on the log (/var/log/firewall).
Then, I shut down the firewall (rcSuSEfirewall stop) but nothing worked, as expected, because it’s the firewall that passes packets between the 192.168.5.0/24 and the 192.168.10.0/24 subnets.
Any clue of what’s causing this mess? Thanks for helping.
PS: I replaced the schematics because the old one had wrong IPs at the Linux server and Server B. I think it has no effect on the tests we’ve been doing.
Are You sure You have the logging of droped packets enabled (I think it’s disabled by default but not sure) ? It can be configured with YAST.
Try to traceroute Server B from Server A (this will give You the partial path) and then traceroute Server A from Server B (this will give You the full path the packets need to traverse as it works in this direction if I understand your description correctly). Compare the outputs and this should reveal where the packets actually go or get droped and hopefully reveal the real problem.
Of course remember not to post the full output of traceroute commands here as it can potentially compromise your security
As a side note I noticed that You’re running openSUSE 10. Are You aware that it’s not supported and has lots of security issues ?
Please consider and upgrade or total reinstall to 11.3 or wait for 11.4 for the longer lifespan.
Hello Greg.
I’m sorry for not pasting updates for so long. The problem is solved.
The routers were misconfigured on both ends. After we followed Dreytek’s instructions for configuring it to the VPN, all we had to do was to update the static routes on the Linux server.
We just need to make some changes in the firewall config and we’re done.
Thanks so much for your help. It would be so much harder without your contribution.
and hopefully reveal the real problem.