Hi all, Just wondering if VPN inside VPN is possible? I've created PPTP VPN in the office. Then from home, first I need to use company's official AT&T VPN. Then after connected, I fire up the PPTP VPN client. Got connected, but cannot ping the PPTP gateway, and half minute later the PPTP got disconnected. No obvious error message in the PPTP log.
Thank you.
Fajar Priyanto writes:
Hi all, Just wondering if VPN inside VPN is possible? I've created PPTP VPN in the office. Then from home, first I need to use company's official AT&T VPN. Then after connected, I fire up the PPTP VPN client. Got connected, but cannot ping the PPTP gateway, and half minute later the PPTP got disconnected. No obvious error message in the PPTP log.
How is this related to centos?
-- Nux! www.nux.ro
On 09/02/2011 15:46, nux@nux.ro wrote:
Fajar Priyanto writes:
Hi all, Just wondering if VPN inside VPN is possible? I've created PPTP VPN in the office. Then from home, first I need to use company's official AT&T VPN. Then after connected, I fire up the PPTP VPN client. Got connected, but cannot ping the PPTP gateway, and half minute later the PPTP got disconnected. No obvious error message in the PPTP log.
How is this related to centos?
quite.... but at first glance this looks like a MTU problem.
On 10/02/11 02:52, Giles Coochey wrote:
On 09/02/2011 15:46, nux@nux.ro wrote:
Fajar Priyanto writes:
Hi all, Just wondering if VPN inside VPN is possible? I've created PPTP VPN in the office. Then from home, first I need to use company's official AT&T VPN. Then after connected, I fire up the PPTP VPN client. Got connected, but cannot ping the PPTP gateway, and half minute later the PPTP got disconnected. No obvious error message in the PPTP log.
How is this related to centos?
quite.... but at first glance this looks like a MTU problem.
Except that not even a tiny ping packet can get through.
VPN inside a VPN should certainly work, although its very inefficient.
Sounds more like a routing issue, perhaps a return route is missing?
Perhaps the OP should sniff his tunnel end-point to see what, if anything, is making its way back.
The OP should also care to include the output of the ping command, rather than saying "cannot ping the PPTP gateway".
On 02/09/2011 09:35 AM, Cameron Kerr wrote:
On 10/02/11 02:52, Giles Coochey wrote:
On 09/02/2011 15:46, nux@nux.ro wrote:
Fajar Priyanto writes:
Hi all, Just wondering if VPN inside VPN is possible? I've created PPTP VPN in the office. Then from home, first I need to use company's official AT&T VPN. Then after connected, I fire up the PPTP VPN client. Got connected, but cannot ping the PPTP gateway, and half minute later the PPTP got disconnected. No obvious error message in the PPTP log.
How is this related to centos?
quite.... but at first glance this looks like a MTU problem.
Except that not even a tiny ping packet can get through.
VPN inside a VPN should certainly work, although its very inefficient.
Sounds more like a routing issue, perhaps a return route is missing?
Perhaps the OP should sniff his tunnel end-point to see what, if anything, is making its way back.
The OP should also care to include the output of the ping command, rather than saying "cannot ping the PPTP gateway". _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I would also look at routing. When the second vpn comes up, it may be configured to alter the routing table which would then try to route the first vpn through the second and the second through the first. This is often done intentionally since you don't want users connecting into a secure network while simultaneously accessing a less secure resource. In fact when the client is connected, Internet traffic is often routed through the VPN as well, so you know that everything they do is behind a secure firewall. You'd be amazed at the software I've seen users try to install on their PC's and then connect to a secure network with.
Another problem is that pptp is udp only and cannot be tunneled through a firewall easily like openvpn or ipsec, so if there is any kind of nat going on when you connect through the first vpn, it won't work because you won't get your packets back. If you were able to use openvpn tcp or IPSEC in a tcp tunneling configuration, it should work.
Nataraj
On 02/09/2011 12:01 PM, Nataraj wrote:
I would also look at routing. When the second vpn comes up, it may be configured to alter the routing table which would then try to route the first vpn through the second and the second through the first.
That sounds mostly right. Many VPNs will take the default route in one manner or another, so the OP's PC probably ends up trying to route packets to the first VPN server through the second VPN tunnel. Routes with one VPN usually look like:
Destination Gateway: local broadcast vpn1-server original default gateway default vpn1-default-gateway
And then when the second one comes up, it looks like:
Destination Gateway: local broadcast vpn2-server vpn1-default-gateway default vpn2-default-gateway
...At that point, you no longer have a route to the first VPN server that works, so you can't reach anything.
Another problem is that pptp is udp only and cannot be tunneled through a firewall easily like openvpn or ipsec, so if there is any kind of nat going on when you connect through the first vpn, it won't work because you won't get your packets back. If you were able to use openvpn tcp or IPSEC in a tcp tunneling configuration, it should work.
Actually, PPTP tunnels use GRE packets. I can't think of any reason that you wouldn't be able to tunnel those, but many NAT devices definitely can't handle them (or can't handle more than one simultaneous GRE session).
On 2/9/2011 2:40 PM, Gordon Messmer wrote:
Another problem is that pptp is udp only and cannot be tunneled through a firewall easily like openvpn or ipsec, so if there is any kind of nat going on when you connect through the first vpn, it won't work because you won't get your packets back. If you were able to use openvpn tcp or IPSEC in a tcp tunneling configuration, it should work.
Actually, PPTP tunnels use GRE packets. I can't think of any reason that you wouldn't be able to tunnel those, but many NAT devices definitely can't handle them (or can't handle more than one simultaneous GRE session).
This may not be the problem here and might not even apply anymore, but long, long ago I noticed that if you were doing nat with iptables and sent a GRE packet out the wrong interface (e.g. before the interface with the correct route came up), the mapping would be stuck in the conntrack table and the route would never switch to the right interface after the correct interface/route was available.
On Thu, Feb 10, 2011 at 5:20 AM, Les Mikesell lesmikesell@gmail.com wrote:
On 2/9/2011 2:40 PM, Gordon Messmer wrote:
Another problem is that pptp is udp only and cannot be tunneled through a firewall easily like openvpn or ipsec, so if there is any kind of nat going on when you connect through the first vpn, it won't work because you won't get your packets back. If you were able to use openvpn tcp or IPSEC in a tcp tunneling configuration, it should work.
Actually, PPTP tunnels use GRE packets. I can't think of any reason that you wouldn't be able to tunnel those, but many NAT devices definitely can't handle them (or can't handle more than one simultaneous GRE session).
This may not be the problem here and might not even apply anymore, but long, long ago I noticed that if you were doing nat with iptables and sent a GRE packet out the wrong interface (e.g. before the interface with the correct route came up), the mapping would be stuck in the conntrack table and the route would never switch to the right interface after the correct interface/route was available.
That's most interesting thoughts guys. Thank you. It's using Centos 5.5. One more info, the PPTP doesn't work in my office wireless network. Google says it may be related to fact that the wireless routers may not be set to allow GRE. At home I'm using wireless too, but doesn't have access to the wifi admin (it's my roommates'). I'll try using cable and take a look at all your suggestions.
-
Cameron Kerr -
Fajar Priyanto -
Giles Coochey -
Gordon Messmer -
Les Mikesell -
Nataraj -
nux＠li.nux.ro