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?
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
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
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
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.
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
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 pfSense
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
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 is
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 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 somewhat
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
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:
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
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
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,
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
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
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 $lan
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
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
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
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
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
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
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
[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
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's
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
33 matches
Mail list logo
