[pfSense-discussion] Certificates with pfsense IPSEC
Hello Again, I would like to subscribe the help of someone who is familiar with the creation of IPSEC VPN tunnels, using certificates. We have successfully used pfsense with shared secrets and we now want to test the use of certificates as an authentication source. I have had my class using pfsense for LAN/WAN simulations, the ability to use VLANs is one of the unique features of pfsense and the primary reason we use it. There doesnt appear to be anything in the tutorials and or m0n0wall docs. If successful I can help with a tutorial on this item. Best Regards Dave Arthur Network Technology Faculty Nova Scotia Community College Canada
Re: [pfSense-discussion] licience of php interface ?
On 2/28/06, Adam Gibson [EMAIL PROTECTED] wrote: Just to be sure we are on the same page. I am referring to static port mappings. Not static IP NAT mappings. I am pretty sure most firewalling filters can do static IP mappings through NAT (1 to 1, etc). Basically just making sure that the src port stays the same during the NAT traversal. Where 10.10.10.10 is LAN client behind firewall NAT Where 12.1.1.1 is some internet server Where Firewall WAN has ip 69.1.1.1 src 10.10.10.10:1000 dst 12.1.1.1:2 | firewall with IP 69.1.1.1 | src 69.1.1.1:1000 dst 12.1.1.1:2 The static-port feature only exists in pf from 5.x versions of freebsd. I am very confident you wont find that feature in ipfilter on freebsd. I looked for an equivalent feature and it just wasn't there. IPFilter does this by default. To quote the man page: For map rules, the destination address will be one for which the tuple combining the new source and destination is known to be unique. If the packet is either a TCP or UDP packet, the destination and source ports come into the equation too. If the tuple already exists, IP Filter will increment the port number first, within the available range speci- fied with portmap and if there exists no unique tuple, the source address will be incremented within the specified netmask. If a unique tuple cannot be determined, then the packet will not be translated. And the BNF syntax: map ::= mapit ifname ipmask - dstipmask [ mapport ] mapoptions. map ::= mapit ifname fromto - dstipmask [ mapport ] mapoptions. . . . mapport ::= portmap tcpudp portspec . portmap is not a require parameter. Also, the ipf howto (dated Dec 11, 2002) on obfuscation.org also claims this to be default IPFilter behaviour. http://www.obfuscation.org/ipf/ipf-howto.html#TOC_29 pf can also do it, we could generate the rules to do it by default. We don't. FWIW, in FreeBSD pf has only been in tree since 5.3, you won't find it available on m0n0 which is IPFilter based. I can't speak any more towards m0n0's usage of IPFilter as I don't use m0n0, never have, never will - nor have I ever seen m0n0's code outside of what we've imported into our tree (which no longer includes the IPFilter code). - Time rules without needing scripts or cron jobs. Yeah, that's never going to happen in PF, nor should it. Cron was designed to schedule jobs to run, it can do a perfectly adequate job, we just need to write the code. opinions are just that... everyone has one. So you would rather have a cron script inject and remove rules than have the filter code take care of it? This just works in iptables and works well. Yes, I would. I don't see the need to make the kernel code more complex. Stateful inspection code is already complex enough without contaminating it with time management code that doesn't belong there. Userland can handle this just fine and should. - conntrack(nat) modules for irc, amanda, netbiosns, and many other modules to make protocols work or work better by default without needing helper applications to get them working behind NAT. The NAT modules just aren't there yet as nobody with the skill and desire has written them. I agree that it's a pain, but I personally find the linux filtering engines to be a pain to work with too. Hince wanting to use iptables. It has more features that I personal need. As far as being a pain, I would disagree. Everyone has their opinions and so there is no right or wrong here. As long as we are both happy :). That is what choice is all about with Linux, *bsd, etc. It's all free and all good. Just have to choose what works for you. - Ability to pick from a bunch of extra features in patch-o-matic for even more nat modules and such. sounds scary Not as long as you don't grab alpha quality modules :). Being in control of picking them makes the difference. - different logging features. Ability to put a text description in syslog logging messages for firewall rules. Hrm, that may actually already be doable, we just don't expose it. I've got better ideas along these lines anyway. Again... this just works the way I want with iptables hince wanting to use it for my firewalling needs. - Ability to push accept/drop/reject decisions to userspace using ipq. Imagine a firewall that blocks everything by default and then when you run the firewall administration web page, any new connections will be displayed and allow the user to accept or deny it so that the user can automatically generate rules based on that information. I mainly use this for creating zonealarm type functionality on Linux currently where a gui X windows comes up asking the user to allow are reject any incoming or outgoing connections. There are good reasons to not do that. With that said, it's trivial to do
Re: [pfSense-discussion] licience of php interface ?
Bill Marquette wrote: Opinions aside. My intent was to get access to his code because for my purposes I would rather use iptables because it has the features that I need without needing a bunch of helper code to get some things working or not having an equivalent feature. Not to mention it would be easier for me to work on it. Fair enough. Bringing up iptables on this list however, is just asking for the conversation that just happened. I was afraid of that but since someone else brought it up I was hoping to get more info from him. I'd love to know what our interface has that the half million gui's for iptables don't have though, I really don't understand the desire to port it. Goes for M0n0 and pfsense... 1. Easily upgrading from one release to another on an embedded flash platform without a video card, keyboard, or mouse for one :). 2. Config file is one config.xml file. Nice and neat. Very nice indeed. No open source embedded linux firewalls have this feature that I have seen. Most embedded firewalls on Linux either are floppy based or hd based. The flash based versions tend to not be upgradable over the network remotely and not easy to setup initially. This is what makes pfsense(and m0n0wall) shine. Everyone has done a great job it seems. Truthfully... I tend to like m0n0wall's look for an interface better than pfsense. Crap... there goes my opinions leaking out. It is the features of pfsense that make up for it though :).
Re: [pfSense-discussion] licience of php interface ?
Isn't a lot of this substantially lower layer feature? A lot (not the static udp stuff) of what you're wanting is pf level development work. That said, last time I had looked at the pf list (which was a whiile ago) they were not interested in adding a lot of goo into pf, but instead keeping it as thin and clean as they could. Adding things like mac filtering, l7 filtering, timing functions are not pf's core competency and, in my opinion, are better handled by userland code. Jumbling a lot of extra features into the filtering system is a very easy way to make it hard to debug and cumbersome to configure. Like I said, just my opinion. nb On Feb 28, 2006, at 4:23 PM, Adam Gibson wrote: On Tue, 2006-02-28 at 13:53 -0600, Bill Marquette wrote: On 2/28/06, Adam Gibson [EMAIL PROTECTED] wrote: - static UDP source ports by default. No need to create special NAT mappings with pfsense which is cumbersome. This solves problems hosting game servers(where the master server uses the source port that it receives from the game server when listing the game server to others. Note that m0n0wall can't support this at all from all the information I have found currently because the packet filter in 4.x bsd doesn't support it. The static-port option was created as a pf feature in some version of 5.x bsd and not ipf. I believe that's incorrect. I'm reasonably confident that IPFilter can do static mappings on it's NAT. Just to be sure we are on the same page. I am referring to static port mappings. Not static IP NAT mappings. I am pretty sure most firewalling filters can do static IP mappings through NAT (1 to 1, etc). Basically just making sure that the src port stays the same during the NAT traversal. Where 10.10.10.10 is LAN client behind firewall NAT Where 12.1.1.1 is some internet server Where Firewall WAN has ip 69.1.1.1 src 10.10.10.10:1000 dst 12.1.1.1:2 | firewall with IP 69.1.1.1 | src 69.1.1.1:1000 dst 12.1.1.1:2 The static-port feature only exists in pf from 5.x versions of freebsd. I am very confident you wont find that feature in ipfilter on freebsd. I looked for an equivalent feature and it just wasn't there. This just works with iptables for UDP connections through NAT. With pf you have to specify an advanced NAT mapping and it applies to TCP too. I want TCP to keep a semi-random source address when going through nat. To keep from TCP being affected I have to specify a dst IP with the NAT mapping so that it only affects connections to that one server. The advanced NAT mapping is just one more thing to have to configure with pf/pfsense. - Time rules without needing scripts or cron jobs. Yeah, that's never going to happen in PF, nor should it. Cron was designed to schedule jobs to run, it can do a perfectly adequate job, we just need to write the code. opinions are just that... everyone has one. So you would rather have a cron script inject and remove rules than have the filter code take care of it? This just works in iptables and works well. - conntrack(nat) modules for irc, amanda, netbiosns, and many other modules to make protocols work or work better by default without needing helper applications to get them working behind NAT. The NAT modules just aren't there yet as nobody with the skill and desire has written them. I agree that it's a pain, but I personally find the linux filtering engines to be a pain to work with too. Hince wanting to use iptables. It has more features that I personal need. As far as being a pain, I would disagree. Everyone has their opinions and so there is no right or wrong here. As long as we are both happy :). That is what choice is all about with Linux, *bsd, etc. It's all free and all good. Just have to choose what works for you. - Ability to pick from a bunch of extra features in patch-o-matic for even more nat modules and such. sounds scary Not as long as you don't grab alpha quality modules :). Being in control of picking them makes the difference. - different logging features. Ability to put a text description in syslog logging messages for firewall rules. Hrm, that may actually already be doable, we just don't expose it. I've got better ideas along these lines anyway. Again... this just works the way I want with iptables hince wanting to use it for my firewalling needs. - Ability to push accept/drop/reject decisions to userspace using ipq. Imagine a firewall that blocks everything by default and then when you run the firewall administration web page, any new connections will be displayed and allow the user to accept or deny it so that the user can automatically generate rules based on that information. I mainly use this for creating zonealarm type functionality on Linux currently where a gui X windows comes up asking the user to allow are reject any incoming or outgoing connections. There are good reasons to not do
Re: [pfSense-discussion] licience of php interface ?
On 2/28/06, Adam Gibson [EMAIL PROTECTED] wrote: [snip] Truthfully... I tend to like m0n0wall's look for an interface better than pfsense. Crap... there goes my opinions leaking out. It is the features of pfsense that make up for it though :). Forgive me for nitpicking, but have you checked out the other 2 themes? Scott
