I am using an ftp-server behind pfsense (beta4) with NAT.
I have problems with ftp-clients in passive mode witch are also behind a
firewall with NAT to browse the ftp-directory.
I know there were few discussions about this, but is
there a solution or workaround to get it working?
Regar
On Jun 1, 2006, at 13:37 , Bernhard Ledermann wrote:
I am using an ftp-server behind pfsense (beta4) with NAT. I have
problems with ftp-clients in passive mode witch are also behind a
firewall with NAT to browse the ftp-directory.
I know there were few discussions about this, but is there a
Enable the FTP helper on Interfaces -> WAN. Reboot.
On 6/1/06, Bernhard Ledermann <[EMAIL PROTECTED]> wrote:
I am using an ftp-server behind pfsense (beta4) with NAT. I have problems
with ftp-clients in passive mode witch are also behind a firewall with NAT
to browse the ftp-directory.
I k
Scott Ullrich wrote:
Enable the FTP helper on Interfaces -> WAN. Reboot.
Should the FTP helper then run and be bound to the WAN-interface?
I can see all the other FTP-helpers bound on most other interfaces, but
I can't see it being bound to the WAN.
(This on a late post-beta2-snapshot)
On 6/1/06, Rainer Duffner <[EMAIL PROTECTED]> wrote:
Should the FTP helper then run and be bound to the WAN-interface?
I can see all the other FTP-helpers bound on most other interfaces, but
I can't see it being bound to the WAN.
(This on a late post-beta2-snapshot)
Why are you asking about be
Scott Ullrich wrote:
On 6/1/06, Rainer Duffner <[EMAIL PROTECTED]> wrote:
Should the FTP helper then run and be bound to the WAN-interface?
I can see all the other FTP-helpers bound on most other interfaces, but
I can't see it being bound to the WAN.
(This on a late post-beta2-snapshot)
Why a
Hi guys
I've talked to three people now, and like me they can see only one
lonely use case for per-interface rules: anti-spoofing.
Seeing as anti-spoofing is largely automated in pfSense and m0n0wall,
is there any compelling reason for this odd division of the rulebase?
It makes the rules hard
Hi everyone,
I just installed 1.0-BETA4 on a Soekris Net4801 and for the most part
everything is working great with the exception of NAT Reflection. I have
a single WAN IP on sis1 and sis0 is my LAN interface. I have a server
on the LAN to which I am forwarding ports 22,25,80 among others. Sin
On 6/1/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
Hi guys
I've talked to three people now, and like me they can see only one
lonely use case for per-interface rules: anti-spoofing.
Seeing as anti-spoofing is largely automated in pfSense and m0n0wall,
is there any compelling reason for this
Bill Marquette wrote:
I'm not sure I see that as a hassle. I'd be more surprised when a
rule matched on an interface I wasn't expecting it to match on.
I asked for use cases, that's not a use case.
You're just saying that you expect the current layout, but the reasons
for that could be anythi
On 6/1/06, Bill Marquette <[EMAIL PROTECTED]> wrote:
On 6/1/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
> Hi guys
>
> I've talked to three people now, and like me they can see only one
> lonely use case for per-interface rules: anti-spoofing.
>
> Seeing as anti-spoofing is largely automated in
Scott Ullrich wrote:
I agree with Bill.
Covered that one ;-).
Not to mention we inherited this behavior from m0n0wall.
Can't see how that translates to "has a real use cases besides antispoofing".
-
To unsubscribe, e-mail:
In addition, why are you cross posting between m0n0wall
and pfSense lists? This is surely not a good idea.
Eep. Really?
I was trying to get as many relevant people's attention as possible,
so that if anyone has a true use case, they can come forward and
convince me that I'm wrong.
I guess I
On 6/1/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
> In addition, why are you cross posting between m0n0wall
> and pfSense lists? This is surely not a good idea.
Eep. Really?
Yes really. pfSense is a fork of m0n0wall. Not everyone agree's with
us forking from m0n0wall so cross-posting
Anti-spoofing is important and a sufficient use case. Please try to
convince us why we're wrong. We're not going to spend any time trying
to convince you why we're right.
--Bill
On 6/1/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
Scott Ullrich wrote:
> I agree with Bill.
Covered that one ;
On 6/1/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
Scott Ullrich wrote:
Can't see how that translates to "has a real use cases besides antispoofing".
Instead of arguing of why and how evolution of the m0n0wall -> pfSense
ruleset has come to be why not tell us how you envision it should
work.
On Thu, Jun 01, 2006 at 02:32:48PM -0400, Scott Ullrich wrote:
> Yes really. pfSense is a fork of m0n0wall. Not everyone agree's with
> us forking from m0n0wall so cross-posting is somewhat rubbing the fact
> in everyones face.
Dunno, I use both (m0n0 at work, pfsense at home). Both
are somewha
Not sure how you are ending up with 'any' in your ruleset as mine
targets the WANIP:
# Reflection redirects
rdr on $lan proto tcp from any to XXX.XXX.89.4 port { 22 } ->
127.0.0.1 port 19000
On 6/1/06, Yuri Lukin <[EMAIL PROTECTED]> wrote:
Hi everyone,
I just installed 1.0-BETA4 on a Soekris
On 6/1/06, Eugen Leitl <[EMAIL PROTECTED]> wrote:
Dunno, I use both (m0n0 at work, pfsense at home). Both
are somewhat complementary, and I frequently direct posters
who look for missing functionality in m0n0 which is present
in pfsense here.
There's certainly some overlap in both communities.
Bill Marquette wrote:
Anti-spoofing is important and a sufficient use case.
It certainly is.
Only I think that having a rulebase per interface just for this is
overengineering things, because it makes all other rule work (besides
antispoofing) needlessly complicated.
Scott Ullrich wrote:
wh
Wait! There's more.
Ok, this is truly mostly a joke, but anyway might help visualize the idea :-).
== (moreover)
There should be a fancy button that produces a SVG showing the
firewall in the middle, the interfaces sticking out from it, and all
the networks as fluffy white
Bill Marquette wrote:
anti-spoofing is _not_ automated...the antispoof rules/syntax only
protect the firewalls interfaces itself, not networks behind it.
I'm having a hard time grasping the exact automatic anti-spoofing
rules in pfSense, I think because they are not visually exposed
anywhere in
You're not thinking this problem out nearly well enough. A master rule
set, especially for those of us with more complex networks would be
unmanageable. Right now, I have a 3 NIC firewall configuration handling
over 65 publicly addressable machines, and when you factor in VPN
interfaces, that
my response to the m0n0wall list (and let's keep this on one list or the
other from now on):
Can you name a firewall vendor that doesn't do per-interface rulesets?
(I'm sure there are some, but virtually all do per-interface) Or one
good reason it shouldn't be this way?
The vast majority of th
Molle Bestefich wrote:
Bill Marquette wrote:
anti-spoofing is _not_ automated...the antispoof rules/syntax only
protect the firewalls interfaces itself, not networks behind it.
I'm having a hard time grasping the exact automatic anti-spoofing
rules in pfSense, I think because they are not visu
Can you point me in the right direction on how to troubleshoot this issue?
I can post my rules.debug or anything else requested.
Thanks,
-Yuri
Scott Ullrich wrote ..
> Not sure how you are ending up with 'any' in your ruleset as mine
> targets the WANIP:
>
> # Reflection redirects
> rdr on $la
Gary Buckmaster wrote:
A master rule set, especially for those of us with more complex networks
would be unmanageable. Right now, I have a 3 NIC firewall configuration
handling over 65 publicly addressable machines, and when you factor in
VPN interfaces, that list of rules alone is pretty beefy.
Okay, I got it. Since I think pf Sense rocks and I have experience with 4 or 5
firewall types, I will spend 5 min/day away from family and work to spec out
improvements to pfSense. Real formal stuff that we can all vet. I can draw from
experience with:
Checkpoint FW1 4.1 & NG
Cisco PIX 515
IP C
On 6/1/06, Chris Buechler <[EMAIL PROTECTED]> wrote:
most of them wouldn't know they should put them in there anyway.
unless this has changed in pfsense, Bill isn't right unless I'm
misunderstanding what he's saying.
In m0n0wall, it automatically builds hidden antispoofing rules based
upon the
Like I just said on the m0n0wall list, what this really comes down to is
a matter of personal preference. Cisco does per-interface, Check Point
and MS ISA do one long unmanageable ruleset. If you don't like
per-interface, go use Check Point or MS ISA. Obviously the developers
here prefer per
We do no anti-spoofing based on subnets. This is the extent of our
anti-spoofing rules.
# LAN/OPT spoof check (needs to be after DHCP because of broadcast addresses)
antispoof for fxp1
antispoof for fxp2
The antispoof directive expands to a set of filter rules which will
block all traff
Gary Buckmaster wrote:
Also, just as a general rule of etiquette, if you have an idea involving
a group of people heavily re-writing something they've been working on
for years, it's a good idea to have a very solidly thought out
alternative idea.
Thanks, others have suggested the same.
Maybe I
Chris Buechler wrote:
If you want to drop big names
Hey, you're the one who asked :-).
But fine idea, let's not look at what others do, that's rather pointless anyway.
> If there's no real use cases (as I suspect), then adding complexity
> makes the rulebase harder to figure out.
this isn't
On 6/1/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
Noone has mentioned past discussions or pointed at design notes.
Therefore I assume that the state of affairs is that the developers
hasn't used much time to think about and discuss the merits and
deficiencies of one design versus the other ve
Being a typical netizen and wanting to chime in my $0.02...
Out of curiosity's sake, where did this come from? Are you
approaching from a UI design methodology, or are you a network
designer, or...? Some background might help the engineers (who speak
machine better than meatspace) understand pr
On 6/1/06, Randy B <[EMAIL PROTECTED]> wrote:
Being a typical netizen and wanting to chime in my $0.02...
Out of curiosity's sake, where did this come from? Are you
approaching from a UI design methodology, or are you a network
designer, or...? Some background might help the engineers (who spe
Scott Ullrich wrote:
*snip*
"Fair enough" to all points.
Agreed to all points, except for the "natural use" one - natural for whom?
Network designer, developer, what, how?
Randy B wrote:
Out of curiosity's sake, where did this come from? Are you
approaching from a UI design methodology, o
On 6/1/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
Scott Ullrich wrote:
> *snip*
"Fair enough" to all points.
Agreed to all points, except for the "natural use" one - natural for whom?
Network designer, developer, what, how?
I do all of this. But keep in mind it is open source, people
g
The real issue with the interface-based approach is in more complex
networks. The user has to move from one tab to another, representing
rules associated with a particular interface, in order to modify
multiple rules associated with a particular application.
For example, if a user has an ap
On 6/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
The real issue with the interface-based approach is in more complex
networks. The user has to move from one tab to another, representing
rules associated with a particular interface, in order to modify
multiple rules associated with a partic
[EMAIL PROTECTED] wrote:
While some users are well-disposed to understanding the concepts and
making changes in each “tab”, other users require a complete
visualization of the project.
heh this is the way m0n0wall used to be, a long list of rules on all
interfaces on a single page. Many pe
I find it irrelevant to the discussion what others are doing, though :-).
Simply that this concept is alien to me, and I'm trying to grasp
context - the more outside examples the better. It seems that what
you're looking for is somewhat similar to some of the higher-level
"shiny" bits on Cisco'
On 6/1/06, Chris Buechler <[EMAIL PROTECTED]> wrote:
heh this is the way m0n0wall used to be, a long list of rules on all
interfaces on a single page. Many people begged for tabs. When they
got them, many others moaned about having them. No matter what open
source developers do, somebody is g
43 matches
Mail list logo