On Thu, 2003-07-24 at 16:37, George Vieira wrote: > >Surely there must be some way of doing port-based filtering of ESP > >packets that are known to be bound for the local host. > If the packet isn't intended for the firewall/ipsec server, then > it's forwarded unencrypted to the internal hosts.... I'm sure by > then the data in decrypted right? Because it can't pass an encrypted > packet to a host who isn't using IPSEC. > > Can you put -j LOG rules in the FORWARD chain to filter on it? > Mine appear to pickup port 23 telnet sessions... sorry if what > you want isn't this.. > > > [root@xxxxxxxx root]# iptables -I FORWARD -i ipsec0 -o eth0 -p tcp --dport 23 > [root@xxxxxxxx root]# iptables -L FORWARD -n -v -x > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source destination > 2 104 tcp -- ipsec0 eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 You're using FreeS/WAN, and you're right that it creates an ipsec0 network device where you can see unencapsulated packets. Meanwhile, I'm using the IPsec built-in to Linux v2.6. No user-land daemon. No ipsec0 device. And no port-based filtering of ESP packets. Maybe what I'm asking is going to be a FAQ in a few months when the in-kernel IPsec catches on. I'm fairly convinced that port- or payload-based filtering of IPsec packets isn't presently possible with such that environment. Either something needs to change or I need to get a little smarter. Time to bother the folks on netfilter-devel? -- Rick Kennell <kennell@xxxxxxxxxxxxxx> Purdue University School of Electrical and Computer Engineering
