Paul Wernau wrote: >> I rewrote this rule as the below, but it still didn't work, and >> packets originated from 192.168.1.16 had never been encapsulated via >> IP-IP and tunneled to 10.20.4.108. >> >> # ipfstat -io >> pass out quick on bge0 to ip.tun0:10.20.4.108 from 192.168.1.16/32 to
>> any empty list for ipfilter(in) >> > >I actually think you want something more like this (with in): > >pass in quick on bge0 to ip.tun0:10.20.4.108 from 192.168.1.16/32 to any > >at least from my tests here with a one-interface host I can get the >packets to go out over a simple tunnel that way. > 192.168.1.16 is a local IP, and this packet is originated from local host. So I think it should be "out". Could you paste your configuration? I can try it here. >> this is my VPN configuration, >> > >You're calling it a VPN configuration and/or IPsec tunnel, but it looks >like a simple IP-in-IP tunnel to me. > Yes, I already removed encr_algs and encr_auth_algs from this IP-in-IP tunnel configuration. >> # ifconfig ip.tun0 >> ip.tun0: flags=10008d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,IPv4> mtu >> 1480 index 9 >> inet tunnel src 10.0.110.56 tunnel dst 10.20.4.16 >> tunnel hop limit 60 >> inet 192.168.0.56 --> 10.20.4.108 netmask ffffff00 >> > >You should either see something about encryption algorithms on here or a >reference to see ipsecconf(1m). Otherwise you are simply routing over >the tunnel in the clear and not providing any security. Can you clarify >here? You can create rules with ipsecconf with the "negotiate tunnel" >keyword and allow only packets from 192.168.1.16 to be routed over the >IPsec protected tunnel, with everything else being dropped. > Here I removed the security policy just becase I want to see the clear packets with ethereal, which are not encapsulated in ESP. >> So my intention is to do source routing using ipf rules . >> >> Actually I can ping 10.20.4.108 via this tunnel, which means the tunnel >> works. > >I'm a bit confused, though. Why not just use IPsec and tunnels >normally? Why the source routing? Is it because you want to restrict >the tunnel to just one IP address? Or this there something else we're >missing? > I just want all the packets orginating from local 10.20.4.16 will go through this tunnel. >There's some examples here you might want to look at: > >http://docs.sun.com/app/docs/doc/816-4554/ipsec-mgtasks-5?l=en&a=view&q =negotiate+tunnel > Thanks!! >If you created your ipsecconf(1m) rule like this: > >{ tunnel ip.tun0 negotiate tunnel laddr 192.168.1.16 } ipsec { >[fill-in-encryption-algorithms....] } > >and set up routing and IKE, it seems like it would accomplish your goal. > Only packets originating from 192.168.1.16 would be allowed over the >tunnel. > What you mean here is "allowed". Will all the traffic go through this tunnel regardless of its destination? _______________________________________________ networking-discuss mailing list [email protected]
