Re: [pfSense Support] Source NAT
Hi Chris, Can he just edit the conf file on hand and bypass webgui? On Fri, Dec 18, 2009 at 10:39 AM, Chris Buechler cbuech...@gmail.com wrote: On Fri, Dec 18, 2009 at 3:21 AM, Tapani Tarvainen pfse...@tapanitarvainen.fi wrote: On Fri, Dec 18, 2009 at 02:52:43AM -0500, Chris Buechler (c...@pfsense.org) wrote Source NAT Can this be done with pfSense? Not at this time. Bummer. :-( Are there plans to add it in the future? It will be eventually, I don't know when. It's a pretty minor change I believe, and it may be a requirement for a project I'm working on right now. If that turns out to be the case, it may make 2.0 if it ends up as simple as I think it will be. Otherwise the next release after probably. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org -- честността не е порок - 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] RC3 to RELEASE - Verify
I have a problem with SATA in FreeBSD kernel and upgrade is still no go. On Fri, Dec 18, 2009 at 9:26 AM, Seth Mos seth@xs4all.nl wrote: Op 17-12-2009 11:35, Paul Mansfield schreef: has anyone upgraded a pfsense cluster running 1.2.2-release to 1.2.3? Yes. am using many CARP addresses on WAN and LAN ports, IPSEC, OpenVPN, and advanced outbound nat. I am using multiple WAN connections, 380 IPsec vpn tunnels, roughly a hundred rules and 40 aliases. It is a 8 interface box with 1 lan and multiple opt interfaces, it uses vlans as well. I also use the load balancer for outbound traffic. It uses both port forwarding an 1:1 NAT. I also use the outbound NAT feature to bind to a carp address. It is a carp cluster based on 2 Dell PowerEdge servers with each 6 gigabit ports, one being the sync network, the others used by pfSense. It have about ~30 carp vips or so. 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 -- честността не е порок - 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] Source NAT
On Fri, Dec 18, 2009 at 10:53:40AM +0200, Peter Todorov (pmi...@gmail.com) wrote Hi Chris, Can he just edit the conf file on hand and bypass webgui? Not quite that easy. I took a look at the code, and pfSense doesn't keep the raw pf conf file, but rebuilds it out of its own xml config at every reload, and the code that does that (filter.inc) has any hardwired as source address. I took a stab at hacking filter.inc and modified it so that if there's source-address modifier in the nat rule, it uses it as source in the rdr entry. I tested it with backup/restore: backed config up, added source-address entry, restored, and it seems to work. Somewhat surprisingly the rule even survived adding another NAT rule from the GUI. This is not exactly convenient, however, and I haven't taken a look at the GUI code to see how hard it'd be to make necessary changes there. -- Tapani Tarvainen - 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] Source NAT
Hi Tapani Tarvainen, So the code will be overwritten on reboot - right? If so one simple script that copy the file before rebooting and one script that overwrite original file after boot. Is this sound any sense? On Fri, Dec 18, 2009 at 11:13 AM, Tapani Tarvainen pfse...@tapanitarvainen.fi wrote: On Fri, Dec 18, 2009 at 10:53:40AM +0200, Peter Todorov (pmi...@gmail.com) wrote Hi Chris, Can he just edit the conf file on hand and bypass webgui? Not quite that easy. I took a look at the code, and pfSense doesn't keep the raw pf conf file, but rebuilds it out of its own xml config at every reload, and the code that does that (filter.inc) has any hardwired as source address. I took a stab at hacking filter.inc and modified it so that if there's source-address modifier in the nat rule, it uses it as source in the rdr entry. I tested it with backup/restore: backed config up, added source-address entry, restored, and it seems to work. Somewhat surprisingly the rule even survived adding another NAT rule from the GUI. This is not exactly convenient, however, and I haven't taken a look at the GUI code to see how hard it'd be to make necessary changes there. -- Tapani Tarvainen - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org -- честността не е порок - 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] Source NAT
Hi Tapani, I run away from ugly hacks and thats the reason I am stuck with version 1.2.1 (do not want to recompile the custom kernel and make my disk) tell if that work On Fri, Dec 18, 2009 at 11:41 AM, Tapani Tarvainen pfse...@tapanitarvainen.fi wrote: On Fri, Dec 18, 2009 at 11:21:32AM +0200, Peter Todorov (pmi...@gmail.com) wrote So the code will be overwritten on reboot - right? The actual pf code, yes - the xml config is where permanent configuration is kept. (Caveat: I haven't read the code very thoroughly yet, I only downloaded pfSense first time yesterday, so I may have missed something obvious.) If so one simple script that copy the file before rebooting and one script that overwrite original file after boot. Is this sound any sense? I guess that'd be possible, but in this case modifying filter.inc as I did and putting the changes in the xml file seems easier. It's also more consistent with the rest of the stuff and might allow patching the GUI later without breaking anything or having to undo any ugly hacks. -- Tapani Tarvainen - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org -- честността не е порок - 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] Source NAT
On Fri, Dec 18, 2009 at 11:13:45AM +0200, Tapani Tarvainen (pfse...@tapanitarvai I took a stab at hacking filter.inc and modified it so that if there's source-address modifier in the nat rule, it uses it as source in the rdr entry. Does anybody think it'd be worthwhile to submit that as a patch? Or would someone like to see it otherwise (small enough even for posting on the list, perhaps - 105 line context diff)? It's not very useful in itself, but not dangerous either, as it should have no effect whatsoever unless one manually adds source-address entries to config file. But it would allow using SNAT for those who need it badly enough to edit xml files manually, and it might be useful as a first step towards proper SNAT support later (with GUI and all). -- Tapani Tarvainen - 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] Source NAT
On 18/12/09 10:58, Tapani Tarvainen wrote: On Fri, Dec 18, 2009 at 11:13:45AM +0200, Tapani Tarvainen (pfse...@tapanitarvai I took a stab at hacking filter.inc and modified it so that if there's source-address modifier in the nat rule, it uses it as source in the rdr entry. Does anybody think it'd be worthwhile to submit that as a patch? Or would someone like to see it otherwise (small enough even for posting on the list, perhaps - 105 line context diff)? it does sound useful, even for those who just want to tinker! - 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] RC3 to RELEASE - Verify
On 18/12/09 07:26, Seth Mos wrote: Op 17-12-2009 11:35, Paul Mansfield schreef: has anyone upgraded a pfsense cluster running 1.2.2-release to 1.2.3? Yes. am using many CARP addresses on WAN and LAN ports, IPSEC, OpenVPN, and advanced outbound nat. I am using multiple WAN connections, 380 IPsec vpn tunnels, roughly a hundred rules and 40 aliases. It is a 8 interface box with 1 lan and multiple opt interfaces, it uses vlans as well. I also use the load balancer for outbound traffic. It uses both port forwarding an 1:1 NAT. I also use the outbound NAT feature to bind to a carp address. It is a carp cluster based on 2 Dell PowerEdge servers with each 6 gigabit ports, one being the sync network, the others used by pfSense. It have about ~30 carp vips or so. cool! I have just upgraded some Dell R300s with Xeon x33~~ processors from 1.2.2 to 1.2.3 now, and a core2quad based machine a few days ago, and a dell vostro cor2duo desktop with realtek onboard and PCIe intel. so far so good. not done our production firewalls yet, I'll leave things alone just for now! - 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] Source NAT /tmp/rules.debug
Does anybody think it'd be worthwhile to submit that as a patch? Or would someone like to see it otherwise (small enough even for posting on the list, perhaps - 105 line context diff)? Maybe this could help too: I Found this article because this Guy wanted to add IPv6 stuff to the Rules. Should work for more or less all unsupported additions if You are sed-aware http://remcobressers.nl/2009/08/configuring-native-ipv6-pfsense/comment-page-1/#comment-2161 search for 10_config-ipv6-pf.sh Beat
Re: [pfSense Support] Source NAT
I'd really like to see source NAT added. I've been used to pf on openbsd for a while... it'll let you abuse nat any way you like it, and will still call you the next day. I tried pfsense and actually really liked it a lot. it was eventually the lack of options for NAT that made me switch back... no source distinction and strange collisions complaints when allocating ports (overlaps which wouldnt actually have hindered traffic). On Fri, Dec 18, 2009 at 7:15 AM, Paul Mansfield it-admin-pfse...@taptu.comwrote: On 18/12/09 10:58, Tapani Tarvainen wrote: On Fri, Dec 18, 2009 at 11:13:45AM +0200, Tapani Tarvainen (pfse...@tapanitarvai I took a stab at hacking filter.inc and modified it so that if there's source-address modifier in the nat rule, it uses it as source in the rdr entry. Does anybody think it'd be worthwhile to submit that as a patch? Or would someone like to see it otherwise (small enough even for posting on the list, perhaps - 105 line context diff)? it does sound useful, even for those who just want to tinker! - 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] Source NAT /tmp/rules.debug
On Fri, Dec 18, 2009 at 02:14:30PM +0100, Beat Siegenthaler (bsi...@gmail.com) w Maybe this could help too: I Found this article because this Guy wanted to add IPv6 stuff to the Rules. Should work for more or less all unsupported additions if You are sed-aware http://remcobressers.nl/2009/08/configuring-native-ipv6-pfsense/comment-page-1/#comment-2161 Yeah, that would work, and I'm certainly sed-aware enough, but I still consider that a rather ugly hack - as a commenter there said, I might as well forego pfSense and use plain freeBSD and hand-written pf.conf. If I had pfSense in production use and had to get this working ASAP I might do something like that, but now I'd rather try to do it pfSense way, for maintainability, and also to learn how it works. -- Tapani Tarvainen - 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] Source NAT
I take it there're no rules on this list against sending
patches (and attempt to register at rcs.pfsense.org failed),
so here it goes. Just apply the patch to filter.inc
and edit /cf/conf/config.xml ) by adding something like
source-address172.16.20.5/source-address
in a nat rule and reboot
(or edit saved backup and restore edited version).
--
Tapani Tarvainen
*** filter.inc.ORIG Mon Dec 7 05:12:36 2009
--- filter.inc Fri Dec 18 12:43:28 2009
***
*** 987,992
--- 987,998
else
$extaddr = get_current_wan_address($rule['interface']);
+ /* Source-NAT support */
+ if ($rule['source-address'])
+ $srcaddr = $rule['source-address'];
+ else
+ $srcaddr = any;
+
if (!$rule['interface'] || ($rule['interface'] == wan))
$natif = $wanif;
else if($rule['interface'] == pptp)
***
*** 1053,1061
case tcp/udp:
if($natif) {
if($rule['external-port'] $rule['local-port'])
! $natrules .= {$nordr}rdr on $natif proto { tcp udp } from any to {$extaddr} port { {$extport[0]} } - {$target}{$localport};
else
! $natrules .= {$nordr}rdr on $natif proto { tcp udp } from any to {$extaddr} port { {$extport[0]} } - {$target};
}
break;
case udp:
--- 1059,1067
case tcp/udp:
if($natif) {
if($rule['external-port'] $rule['local-port'])
! $natrules .= {$nordr}rdr on $natif proto { tcp udp } from {$srcaddr} to {$extaddr} port { {$extport[0]} } - {$target}{$localport};
else
! $natrules .= {$nordr}rdr on $natif proto { tcp udp } from {$srcaddr} to {$extaddr} port { {$extport[0]} } - {$target};
}
break;
case udp:
***
*** 1063,1094
if($extport[0])
if($natif) {
if($rule['external-port'] $rule['local-port'])
! $natrules .= rdr on $natif proto {$rule['protocol']} from any to {$extaddr} port { {$extport[0]} } - {$target}{$localport};
else
! $natrules .= rdr on $natif proto {$rule['protocol']} from any to {$extaddr} port { {$extport[0]} } - {$target};
}
else
if($natif)
! $natrules .= rdr on $natif proto {$rule['protocol']} from any to {$extaddr} - {$target}{$localport};
break;
default:
! $natrules .= rdr on $natif proto {$rule['protocol']} from any to {$extaddr} - {$target};
break;
}
} else {
switch ($rule['protocol']) {
case tcp/udp:
if($natif)
! $natrules .= {$nordr}rdr on $natif proto { tcp udp } from any to {$extaddr} port {$extport[0]}:{$extport[1]} - {$target}{$localport}:*;
break;
case udp:
case tcp:
if($natif)
! $natrules .= {$nordr}rdr on $natif proto {$rule['protocol']} from any to {$extaddr} port {$extport[0]}:{$extport[1]} - {$target}{$localport}:*;
break;
default:
if($natif)
! $natrules .= {$nordr}rdr on $natif proto {$rule['protocol']} from any to {$extaddr} - {$target};
}
}
}
--- 1069,1100
if($extport[0])
if($natif) {
if($rule['external-port'] $rule['local-port'])
! $natrules .= rdr on $natif proto {$rule['protocol']} from {$srcaddr} to {$extaddr} port { {$extport[0]} } - {$target}{$localport};
else
! $natrules .= rdr on $natif proto {$rule['protocol']} from {$srcaddr} to {$extaddr} port { {$extport[0]} } - {$target};
}
else
if($natif)
! $natrules .= rdr on $natif proto {$rule['protocol']} from {$srcaddr} to {$extaddr} - {$target}{$localport};
break;
default:
! $natrules .= rdr on $natif proto {$rule['protocol']} from {$srcaddr} to {$extaddr} - {$target};
break;
}
} else {
switch ($rule['protocol']) {
case tcp/udp:
if($natif)
! $natrules .= {$nordr}rdr on $natif proto { tcp udp } from {$srcaddr} to {$extaddr} port {$extport[0]}:{$extport[1]} - {$target}{$localport}:*;
break;
case udp:
case tcp:
if($natif)
! $natrules .= {$nordr}rdr on $natif proto {$rule['protocol']} from {$srcaddr} to {$extaddr} port {$extport[0]}:{$extport[1]} - {$target}{$localport}:*;
break;
default:
if($natif)
! $natrules .= {$nordr}rdr on $natif proto {$rule['protocol']} from {$srcaddr} to {$extaddr} - {$target};
}
}
}
-
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] Source NAT
On Fri, Dec 18, 2009 at 03:45:03PM +0200, Tapani Tarvainen (pfse...@tapanitarvai I take it there're no rules on this list against sending patches (and attempt to register at rcs.pfsense.org failed), so here it goes. Just apply the patch to filter.inc Forgot to mention, this is for 1.2.3 release - I've no idea if it works with any others. -- Tapani Tarvainen - 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] Wake On LAN - Now Works on 1.2.3 Embedded!
- Original Message - From: Chris Weakland chris.weakl...@gmail.com To: support@pfsense.com Sent: Sunday, December 13, 2009 4:40 AM Subject: Re: [pfSense Support] Wake On LAN - Now Works on 1.2.3 Embedded! Also if ur nic is a pci or pcie nic the wol cable must be connected to the motherboard header for it to work with wol. Chris I just tried WOL using an Intel 1000GT PCI NIC, (using no wol cable between the NIC and the motherboard) and it works fine. The tested motherboard is a GA-EP31-DS3L, which (sadly) does not have WOL in the BIOS. Certainly many NIC's and motherboards will need those cables, clearly not always. - 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] Wake On LAN - Now Works on 1.2.3 Embedded!
What you do on client machine? On Sat, Dec 19, 2009 at 6:11 AM, Tortise tort...@paradise.net.nz wrote: - Original Message - From: Chris Weakland chris.weakl...@gmail.com To: support@pfsense.com Sent: Sunday, December 13, 2009 4:40 AM Subject: Re: [pfSense Support] Wake On LAN - Now Works on 1.2.3 Embedded! Also if ur nic is a pci or pcie nic the wol cable must be connected to the motherboard header for it to work with wol. Chris I just tried WOL using an Intel 1000GT PCI NIC, (using no wol cable between the NIC and the motherboard) and it works fine. The tested motherboard is a GA-EP31-DS3L, which (sadly) does not have WOL in the BIOS. Certainly many NIC's and motherboards will need those cables, clearly not always. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org -- честността не е порок - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
