Hao Wu 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. > 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. > # 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. > 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? 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 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. Thanks, Paul _______________________________________________ networking-discuss mailing list [email protected]
