Does the releases before 8/07 release of Solaris 10 support this ipfileter feature?
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] > _______________________________________________ networking-discuss mailing list [email protected]
