[Vpn-help] Loosing default gateway and problems to connect
Matthew Grooms
mgrooms at shrew.net
Tue Mar 20 10:00:05 CDT 2007
On 3/20/2007, "Gustavo Castro" <gcastrop at gmail.com> wrote:
>
> Thank for your response!
> I think I wasn't clear enough in the previous email, and that's my fault.
>I control both networks, the local one (in my house) is a
>192.168.1.0/24(gateway is
>192.168.1.1) and the other is a 192.168.0.0/24 (gateway is 192.168.0.1), so
>address assignation might not be an issue. I get a 192.168.1.11 in the vnet
>adapter (via mode_cfg), and I have 192.168.1.10 in the ethernet adapter. I
>did this as a poor try to connect to the other network without losing
>internet connectivity, because if I start the tunnel, I simply lost all
>other connectivity.
I'm not sure how you are specifying the remote topology. If you do not
have ipsec tools version 7.x ( in beta ) which allows you to specify the
split network include/exclude lists, then you have two choices ...
1) Leave the policy config set to auto. The client will attempt to tunnel
all traffic to the remote peer when it does not receive any
include/exclude information during modecfg.
2) Manually configure an 192.168.0.0/24 include network in the policy
config. This will instruct the client to only tunnel traffic destined to
the 192.168.0.0/24 network.
> The other problem is that I can't connect to to any machine in the
>192.168.0.0/24 network anyway... I can assign any other address (
>192.168.100.10, as an example) to my vnet device via mode_cfg, but it didn't
>work either, so apparently address assignation is not the problem. As I
>can't keep both connections at the same time (to my network and to the vpn),
>I can't check what's going on in the wires (can't sniff it), so I'm blind
>and playing "knock, knock..." with myself... :-(
>
> As I'm using ipsec-tools 0.6.6, I can't use split_network, so I can't tell
>to the other firewall to exclude/include addresses or so (and I don't know
>if it will affect me positively).
> I tried adding different policies in the client (this could be the
>problem), but I didn't find one that fix my issue.
Please use a different network for the modecfg address pool. As I said
before, I think you will continue to have problems if the vnet and the
local adapter are in the same subnet. Its easy to change and will be one
less potential problem to deal with.
> I can send you logs and any other info you may need, and if you want, I
>can send you the .vpn file of the connection I'm using, (without the psk, as
>you may imagine...). Does this list accept attachments? I don't think it
>will be a good idea to put all stuff in a plain mail body...
> I'm pretty sure I must be missing something, but I can't realise what
>could it be...
>
> What do you suggest?
>
Lets try this ....
1) Renumber the modecfg address pool to 192.168.x.0/24
2) Manually add a include policy for 192.168.x.0/24
3) Connect and attempt to ping a host in 192.168.x.0/24
If you are having problems with the default route dropping, please send
me the output of "route print" for before, during and after the
connection attempt.
If you are having problems with packets being tunneled to the
192.168.x.0/24 network, please check that security associations are
being successfully negotiated. These will be visible in the VPN Trace
application. If you don't see any security associations listed after
trying to ping a host in the remote network, there we have a problem
with phase2 not completing.
If there are entries in the security association tab, ( should be two,
one for inbound and one for outbound traffic ) but you are not seeing
ping reply packets, perform a tcpdump on the external interface of the
gateway machine and make sure the esp or natt packets are getting to the
peer.
For example ...
tcpdump -i <external interface name> esp
or
tcpdump -i <external interface name> udp and port 4500
If you see the esp/natt packets getting there from the client but you
don't see return esp/natt packets, check to see if the SA packet
counters are going up for the inbound SA. You can match the SPI shown in
the tcpdump to the SPI shown in the output of the following command ...
setkey -D
If the counter is not going up, then you most likely have an selinux or
firewall rule that is preventing the packet from being received or
forwarded. If the counter is going up, then you need to sniff the
internal interface to see if the ping is being sent to the destination
host. If you are seeing ICMP packets being send and received, then you
need to check the send/forward rules for the other direction.
Anyhow, I am sure you see where I am going with this. If phase1 and
phase2 are completing successfully, the client is basically functioning
as it should. If packets are not being tunneled correctly, the path can
be traced from end to end using the method I describe above. I probably
need to set some better trouble shooting documentation up on the website
so it can be there as a resource.
Hope this helps. Let me know if you need further assistance. I am more
than happy to help out :)
-Matthew
More information about the vpn-help
mailing list