jared r r spiegel wrote: > On Mon, Jul 17, 2006 at 05:25:38PM -0600, Stephen Bosch wrote: >> route add -host 192.168.0.57 -interface enc0 >> >> I get this response: >> >> route: enc0: bad address > > -interface actually takes an address: > > --- > If the destination is directly reachable via an interface requiring no > intermediary system to act as a gateway, the -interface modifier should > be specified; the gateway given is the address of this host on the common > network, indicating the interface to be used for transmission. > --- > > iow, it derives the iface based on what iface the addr you give it > lives on. > >> Even though a security association for the target address exists on >> enc0. Unfortunately, the device is not passing traffic to 192.168.0.57. >> >> I assume I need to add a route -- but is this even necessary? > > you will need to add a route to the other end of the tunnel > so that traffic that originates on the local endpoint destined > for an addr matching the remote addrspec (Destination in netstat > -rnf encap) goes over the tunnel. > > if traffic originates on the local host and a matching route > is found in the inet (or inet6, i suppose) table, that route > is taken. if you have a default route, that will catch it > (probably undesired), so you need an inet route to make it > match something more specific than the default route in the > inet table. > > traffic traversing the host (forwarded datagrams) will match > the ipsec flows before they get looked up against the encap > table (if this is not literally correct, it is the behaviour > i've observed) and thus do not need a route.
I am talking about forwarded datagrams in this case. That's been my experience in the past, but it's not working right now. I'm using a device to NAT traffic from an internal host to the private IP address the remote IPsec peer expects on my end. When I ping from the internal host and do a tcpdump on the internal interface of the IPsec device, I see that the packets have been NATted correctly and I would expect them to be matched to the appropriate flow and passed through to the remote internal network -- yet I get "Destination host unreachable" from the IPsec device. I note that that is not the same as "No route to host", but I remain suspicious. I don't see any of my pings go out on enc0. Just to eliminate the obvious -- the IPsec device is forwarding other traffic just fine, and I have other working tunnels. -Stephen-