You probably have the ftphelper enabled or are scanning from behind another pfSense with ftphelper enabled at LAN. As this is a proxy it wil redirect the traffic through it and cause a connect. This is normal and doesn't mean the other end actually has this port open.

yeah, thanks ulrich, here …

Bill Marquette
Mon, 04 Sep 2006 10:09:44 -0700

Or if you want fuck with the ISP and have a full blown network behind
the pfSense box.

Change the following line in /etc/inc/filter.inc
      $rules .= "scrub all {$scrubnodf} {$mssclamp} fragment
reassemble\n"; // reassemble all directions
to:
      $rules .= "scrub all min-ttl 255 {$scrubnodf} {$mssclamp}
fragment reassemble\n"; // reassemble all directions

That will reset the TTL to 255 (substitute whatever sufficiently high
value appeals to you) as it passes through the pfSense box.  The above
line lives on line 166 in filter.inc version 1.575.2.235.  BTW, this
will have the other added advantage of being able to mask different
OSs behind your pfSense box and the network layout as ALL packets will
have a normalized TTL after traversing the firewall.

I don't expect to ever put a gui wrapper around this, I feel it has
rather limited use.

--Bill

@rcarr:

To fix this issue once you upgrade to 1.2-BETA-1

I'm a little confused after you warned everyone in no uncertain terms not to use any more snapshots or upgrades until the 1.2 release:  http://forum.pfsense.org/index.php/topic,4603.0.html

At this point you should probably run 1.2b1 unless told otherwise, as I said in the linked thread. What Scott said there was just a confirmation of that, and he didn't say "don't use any snapshots until the 1.2 release". As it says in that thread, unless you're told otherwise, don't use snapshots, use the 1.2 beta release. Things can get broken between beta releases, like right now OPT outbound NAT is broken on snapshots but works fine on 1.2b1.

For now, we follow this rule of thumb - If you run into a problem that was probably fixed by a snapshot since the last beta release and there currently is no major breakage in the snapshots, we'll suggest you upgrade to a snapshot. Unless you know, or have been told, that a snapshot is what you should be running, run the official 1.2 beta releases.

http://mxtoolbox.com/ can run tests against smtp too.

It's a bridge which means you have to use the upstream gateway for your clients and not the pfSense. The pfSense is just a transparent inline filter in this scenario.

Thanks! I will test it on Saturday  ;)

@cmb:

Never use ifconfig aliases. They won't survive a reboot, aren't necessary, and is the wrong way to setup additional IP's on pfsense. See the Virtual IP page. Then look at the NAT page, Outbound tab. You'll need to enable Advanced Outbound NAT, and put in your NAT rules as desired.

Thank you,
now 1:1 NAT works!  :)

I have not used Outbound tab because from which I understood "Automatic outbound NAT rule generation (IPSEC passthrough)" is sufficient.

I also had to create a rules on the WAN interface to allow traffic from * to the destination internal address, it works, is it the correct way to let packet pass?

Thank you in advance.

Davide.

Thank you very much, Ben.

Now I understand!

Thanks!

I'll give that a try today.

PF for the main filter set.
IPFW is used for captive portal and firewall schedules.

Yep, I just mentioned it.

/etc/rc.filter_configure_sync

In addition we load the ruleset with pfctl -o which optimizes the ruleset and removes duplicates.

Simply add a rule at the bottom of each screen's rule list to override it.
<<

Here's what happens in rules.debug when I add my own custom catch-all-block to the bottom of Firewall->Rules->WAN:

User-defined rules follow

.
.
.
pass in quick on $lan from 172.19.1.0/24 to any keep state  label "USER_RULE: Default LAN -> any"
pass in quick on $enc0 from any to any keep state  label "USER_RULE: Permit IPSEC traffic."
===> block return-rst in quick on $wan proto tcp from any to any flags S/SA  label "USER_RULE: test return-rst block-all rule" <====

VPN Rules

pass in quick on fxp1 inet proto tcp from any to $loopback port 8021 keep state label "FTP PROXY: Allow traffic to localhost"
pass in quick on fxp1 inet proto tcp from any to $loopback port 21 keep state label "FTP PROXY: Allow traffic to localhost"
–-> pass in quick on fxp0 inet proto tcp from port 20 to (fxp0) port > 49000 user proxy flags S/SA keep state label "FTP PROXY: PASV mode data connection" <---

enable ftp-proxy

pass in quick on fxp2 inet proto tcp from any to $loopback port 8022 keep state label "FTP PROXY: Allow traffic to localhost"
pass in quick on fxp2 inet proto tcp from any to $loopback port 21 keep state label "FTP PROXY: Allow traffic to localhost"

IMSpector

anchor "imspector"

uPnPd

anchor "miniupnpd"

My custom catch-all block rule for the $wan interface (denoted with '===>') appears before the VPN Rules, IMSpector and uPnPd sections.  It now interferes with one of the VPN rules (denoted with '--->').  I don't know what goes in IMSpector or uPnPd, but it's likely any catch-all block rules I'd add to the User-Defined section would interfere with them, as well as any future work you do adding additional sections to rules.debug after the user-defined section.

By definition, catch-all block rules like your "Default block all just to be sure" rules must appear at the end of the pf ruleset.  The WebGUI does not give you the ability to modify them, nor position these kinds of rules at the end.

I'll investigate creating a patch.

@rcarr:

I just think it's more correct to refer to an interface's IP addr by reference "($wan)" than by value.

You might be right.  Mind submitting a patch to change this behavior?

@rcarr:

How/where do I access the tcp.established timeout parm?  Is it "State Timeout in seconds" in the Advanced Options of any rule?

Yep, that's the one.

hi

using  traffic quota for every user, and if the traffic exceed the quota then his internet will be blocked or slow down to minimum bandwidth.

hadi57

Try reinstalling from a recent snapshot iso.

It should still work this way. Make sure all clients at LAN and OPT1 use the correct gateway and have valid IP configuration.

The rules.debug is dynamically regenerated and reloaded when needed (on rulesetchanges, on bootup, on loadbalancer statuschanges, …) and therefore your changes won't stay for very long. What you try to do ist not really supported.