>
> The route command that failed:
> route add -net 216.209.122.80 netmask 255.255.255.255 dev ipsec0 gw
198.64.129.1
>
> Relevant extract from the routing table:
> 198.64.133.68 0.0.0.0 255.255.255.252 U 40 0 0
ipsec0
>
> You cannot get to 216.209.122.80 through ipsec0 according to this
> routing table. You can only get to 198.64.133.68-198.64.133.71
>
> You've got to design another structure. At this point, this isn't a
> FreeS/WAN problem. But FreeS/WAN does constrain solutions.
>
> Perhaps we could help if you told us what you want to achieve.
198.64.133.69 is a server located on the internet. I want it setup to
receive VPN connection from clients on the internet. These connections are
point to point(No subnet exists behind the server). Everything works when I
use the non-virtual IP. Using either of the virtual IP's causes the failures
I have been reporting. Is there somethng magic FS does when %defaultroute is
specified that isn't happesing here? Perhaps a mirror of the default route
from the route table, but with ipsec0 as the interface rather than eth0?
>
> Is 198.64.129.1 happy to accept packets with source addresses in
> 198.64.133.68-198.64.133.71?
AFAIK, A tracereoute confirms it si the gateway used to route packets to
the oustide world form the server
> Are 198.64.133.68-198.64.133.71 routed from the wild world into your
> network?
They are publicly reachable addresses. 69 and 70 are virtual IP's on my
server.
Mike.
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:20:14 CEST