[pfSense Support] Large Aliases
Is there any undocumented tricks to creating large aliases other than by hand? I have some I need to create with maybe 100 or more small networks. Can I import the list at the cli somehow and have the gui acknowledge them? Thanks! jlc - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Large Aliases
You can export a configuration file to see the file structure, build a configuration backup that has the aliases in it based on the sample, and then restore your "backup". That's what we did. -- Moshe Katz KatzNet Computers -- mo...@ymkatz.net -- +1(301)867-3732 On Mon, Aug 23, 2010 at 11:04 AM, Joseph L. Casale < jcas...@activenetwerx.com> wrote: > Is there any undocumented tricks to creating large aliases other than > by hand? I have some I need to create with maybe 100 or more small > networks. Can I import the list at the cli somehow and have the gui > acknowledge them? > > Thanks! > jlc > > - > To unsubscribe, e-mail: support-unsubscr...@pfsense.com > For additional commands, e-mail: support-h...@pfsense.com > > Commercial support available - https://portal.pfsense.org > >
RE: [pfSense Support] Large Aliases
>You can export a configuration file to see the file structure, build >a configuration backup that has the aliases in it based on the sample, >and then restore your "backup". That's what we did. That’s a good idea, but the lists need updating and something scriptable would be easier so I could do this at the cli less obtrusively... Thanks, jlc
[pfSense Support] Routing and virtual IP
We'd like to setup a redundant carp configuration for a couple of routing box with pfsense. Each of two has a dedicated IP on WAN side, and a dedicated IP on routing interface (here are connected other routers and firewalls). Of course, there is a common virtual IP for each side (WAN and routing). Setting up static routes, we see we can declare gateways, but not outgoing IP, so we see we can set VIP as default gateway on external devices, but we cannot impose VIP as preferred outgoing IP on pfsense. Our questions: Will PFsense use VIP or dedicated IP for outgoing packets? Which is the preferred IP? Will PFsense let connections use both VIP and dedicated IP (master) without any state problem? Thanks, Tonino -- in...@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Large Aliases
Quoting Joseph L. Casale (from 24/08/10 04:23): >> You can export a configuration file to see the file structure, build >> a configuration backup that has the aliases in it based on the sample, >> and then restore your "backup". That's what we did. > > That’s a good idea, but the lists need updating and something scriptable > would be easier so I could do this at the cli less obtrusively... You can make some nice scripts with xmlstarlet (http://xmlstar.sourceforge.net/), and automate additions to the configuration from there; but there will always be some interruption when you reload in order to get the new config. Perhaps there's another way; what are you doing this for? Instead of basing rules on a large set of aliases that you have to update regularly, is there some other characteristic you can group your rules by? (AKA 'describe the original problem, not just the one step you're stuck on') -jim - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Large Aliases
Hi, Op 23 aug 2010, om 21:08 heeft Jim Cheetham het volgende geschreven: > Perhaps there's another way; what are you doing this for? Instead of > basing rules on a large set of aliases that you have to update > regularly, is there some other characteristic you can group your rules > by? (AKA 'describe the original problem, not just the one step you're > stuck on') Also, in 2.0 we have support for nested aliases. What you can do with this is pretty straightforward ofcourse. You can then update 1 specific alias which is part of the parent alias. This should make management a lot easier, the chances of error smaller and possibly the number of firewall rules smaller. Regards, Seth - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Large Aliases
On 8/23/2010 3:12 PM, Seth Mos wrote: > Hi, > > Op 23 aug 2010, om 21:08 heeft Jim Cheetham het volgende geschreven: > >> Perhaps there's another way; what are you doing this for? Instead of >> basing rules on a large set of aliases that you have to update >> regularly, is there some other characteristic you can group your rules >> by? (AKA 'describe the original problem, not just the one step you're >> stuck on') > > Also, in 2.0 we have support for nested aliases. What you can do with this is > pretty straightforward ofcourse. You can then update 1 specific alias which > is part of the parent alias. > > This should make management a lot easier, the chances of error smaller and > possibly the number of firewall rules smaller. In 2.0 we also have a URL table alias type that can periodically update its contents from a URL that has IP and IP/CIDR format entries (one per line). We've tried it with 40k+ entries and it works fine. You can't edit the lists on the box though, they only refresh via the contents of the URL. There was no practical way to handle editing that large of a list in the GUI and storing the data in the actual XML file. There is a package for 1.2.3 that imports that functionality as well. Jim - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] Disk boot Error. Packet mode checked
Hi, I´ve been trying to install pfsense 1.2.3 into Supermicro superserver 5030G-M. After LiveCD correct loaded, I performed a quick installation several times, receiving Disk boot Error once the installation was finished First of all, i suspected the bios was blocking write to boot sector (google post), but i checked the bios and not. I googled again for the issue, and then found a mail in archive suggesting to uncheck packed mode in advanced installation, and everything was right. Any explanation about that? THNKS. Regards -- dpc
RE: [pfSense Support] Large Aliases
>> Also, in 2.0 we have support for nested aliases. What you can do with >> this is pretty straightforward ofcourse. You can then update 1 specific >> alias which is part of the parent alias. >> >> This should make management a lot easier, the chances of error smaller >> and possibly the number of firewall rules smaller. > >In 2.0 we also have a URL table alias type that can periodically update >its contents from a URL that has IP and IP/CIDR format entries (one per >line). > >We've tried it with 40k+ entries and it works fine. You can't edit the >lists on the box though, they only refresh via the contents of the URL. >There was no practical way to handle editing that large of a list in the >GUI and storing the data in the actual XML file. > >There is a package for 1.2.3 that imports that functionality as well. This is exactly what I need, the Country Block package was what I wanted but I need finer grained control, so an Alias to work with would do this. A quick pfctl show of the Table enumerated as expected. How does one keep an eye on this? I am confused with the update frequency versus no cron job added msg? Thanks guys! jlc
Re: [pfSense Support] Large Aliases
On 8/23/2010 6:20 PM, Joseph L. Casale wrote: >>> Also, in 2.0 we have support for nested aliases. What you can do with >>> this is pretty straightforward ofcourse. You can then update 1 specific >>> alias which is part of the parent alias. >>> >>> This should make management a lot easier, the chances of error smaller >>> and possibly the number of firewall rules smaller. >> >> In 2.0 we also have a URL table alias type that can periodically update >> its contents from a URL that has IP and IP/CIDR format entries (one per >> line). >> >> We've tried it with 40k+ entries and it works fine. You can't edit the >> lists on the box though, they only refresh via the contents of the URL. >> There was no practical way to handle editing that large of a list in the >> GUI and storing the data in the actual XML file. >> >> There is a package for 1.2.3 that imports that functionality as well. > > This is exactly what I need, the Country Block package was what I wanted > but I need finer grained control, so an Alias to work with would do this. > > A quick pfctl show of the Table enumerated as expected. How does one keep > an eye on this? I am confused with the update frequency versus no cron job > added msg? The cron job isn't automatically added in 1.2.3 (or 2.0 yet, haven't added it to the config, but that should happen soon) but you can add your own cron job to run daily that calls /etc/rc.update_urltables. It's easy to do with the cron package that's out there too. If you want to check the contents of the table, use pfctl -T show -t where is the name of your alias. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] Bug in NAT generator
$natrules .= filter_nat_rules_generate_if($wanif,
"{$lansa}/{$lancfg['subnet']}", 5060, "", 5060, null,
5060, false);
This line in /etc/inc/filter.inc breaks SIP behind NAT. It seems to exclude
5060 from the outbound NAT rules. Why would you want to do that? Am I
misunderstanding what this does? Changing the ports to something else
immediately fixes native SIP functionality.
Seems to me like this is:
A) Bad
B) At least cludgy (random implementation to do one thing only)
C) Not documented in the code or in the interface that I can find
For my sanity, what would be the clean way of removing that line from
filter.inc? I'm not a programmer, so I just changed the numbers to a port I'm
not using, but I'd rather get rid of it altogether. ;)
Best Regards,
Nathan Eisenberg
Re: [pfSense Support] Bug in NAT generator
On Mon, Aug 23, 2010 at 8:37 PM, Nathan Eisenberg
wrote:
> $natrules .= filter_nat_rules_generate_if($wanif,
>
> "{$lansa}/{$lancfg['subnet']}", 5060, "", 5060,
> null, 5060, false);
>
>
>
> This line in /etc/inc/filter.inc breaks SIP behind NAT. It seems to exclude
> 5060 from the outbound NAT rules. Why would you want to do that? Am I
> misunderstanding what this does? Changing the ports to something else
> immediately fixes native SIP functionality.
>
At the time that was done (many years ago), not rewriting 5060 fixed
things more often than it broke them. That's no longer the case, 2.0
does not do that by default. It is documented and intended behavior,
but since changed. Enable advanced outbound NAT if you don't want
that.
-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
