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] 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
172.16.20.5
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 /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'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 wrote: > 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 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
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
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 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
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 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 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
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 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: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
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 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 modifier in the nat rule, it uses it > as source in the rdr entry. I tested it with backup/restore: > backed config up, added 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
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 modifier in the nat rule, it uses it as source in the rdr entry. I tested it with backup/restore: backed config up, added 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 Chris, Can he just edit the conf file on hand and bypass webgui? On Fri, Dec 18, 2009 at 10:39 AM, Chris Buechler wrote: > On Fri, Dec 18, 2009 at 3:21 AM, Tapani Tarvainen > 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] Source NAT
On Fri, Dec 18, 2009 at 3:21 AM, Tapani Tarvainen 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
Re: [pfSense Support] Source NAT
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? -- 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 Fri, Dec 18, 2009 at 2:09 AM, Tapani Tarvainen wrote: > Hi, > > I'm new to pfSense, trying to evaluate its suitability for > my needs, to replace an old custom freebsd firewall, > and while it looks very nice otherwise, there's one > feature I can't find: Source NAT, i.e., redirection > depending on source IP. > > Here's a sample pf.conf entry from the old box to > clarify what I mean: > > rdr on $ext_if proto tcp from 172.16.249.93 to $ext_if port 22 -> $host1 > port 22 > > Can this be done with pfSense? Not at this time. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
