try this: translate ID–->ENGLISH http://forum.pfsense.org/index.php/topic,29019.0.html http://code.google.com/p/pfsense-zph/downloads/list ;D

Do you have a firewall pass rule on both interfaces that will allow traffic to the other network? Is this pass rule above any rule that would block the traffic?

I never thought to use an alias to simplify the entry, thanks for the suggestion.  I will give it a shot!

rl0=wan–>pppoe re0=lan-->192.168.1.1/24 [2.0.1-RELEASE][root@blala.lalalala.com]/root(1): ifconfig -a re0: flags=108843 <up,broadcast,running,simplex,multicast,ipfw_filter>metric 0 mtu 1492         options=389b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_ucast,wol_mcast,wol_magic>ether 00:27:0e:07:83:14         inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255         inet6 fe80::227:eff:fe07:8314%re0 prefixlen 64 scopeid 0x1         nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)         status: active rl0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500         options=8 <vlan_mtu>ether 00:26:5a:eb:55:f5         inet6 fe80::226:5aff:feeb:55f5%rl0 prefixlen 64 scopeid 0x2         nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)         status: active lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384         options=3 <rxcsum,txcsum>inet 127.0.0.1 netmask 0xff000000         inet6 ::1 prefixlen 128         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3         nd6 options=3 <performnud,accept_rtadv>pfsync0: flags=0<> metric 0 mtu 1460         syncpeer: 224.0.0.240 maxupd: 128 syncok: 1 pflog0: flags=100 <promisc>metric 0 mtu 33200 enc0: flags=0<> metric 0 mtu 1536 pppoe0: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1492         inet 1xx.xxx.xxx.41 –> 1xx.xxx.xxx.1 netmask 0xffffffff         inet6 fe80::227:eff:fe07:8314%pppoe0 prefixlen 64 scopeid 0x7         nd6 options=3 <performnud,accept_rtadv>ipfw0: flags=8801 <up,simplex,multicast>metric 0 mtu 65536 [2.0.1-RELEASE][root@blala.lalalala.com]/root(2): netstat -rn Routing tables Internet: Destination        Gateway            Flags    Refs      Use  Netif Expire default            12x.xxx.xxx.1      UGS        0  5375425 pppoe0 8.8.4.4            12x.xxx.xxx.1      UGHS        0    50647 pppoe0 8.8.8.8            12x.xxx.xxx.1      UGHS        0    66679 pppoe0 12x.xxx.xxx.1      link#7            UH          0    43624 pppoe0 12X.xxx.xxx.41    link#7            UHS        0      11    lo0 127.0.0.1          link#3            UH          0    7178    lo0 192.168.1.0/24    link#1            U          1  7434973    re0 192.168.1.1        link#1            UHS        0        0    lo0 20x.xxx.x.10      12x.xxx.xxx.1      UGHS        0    50647 pppoe0 208.67.222.222    12X.xxx.xxx.1      UGHS        0    50647 pppoe0 Internet6: Destination                      Gateway                      Flags      Netif Expire ::1                              ::1                          UH          lo0 fe80::%re0/64                    link#1                        U          re0 fe80::227:eff:fe07:8314%re0      link#1                        UHS        lo0 fe80::%rl0/64                    link#2                        U          rl0 fe80::226:5aff:feeb:55f5%rl0      link#2                        UHS        lo0 fe80::%lo0/64                    link#3                        U          lo0 fe80::1%lo0                      link#3                        UHS        lo0 fe80::%pppoe0/64                  link#7                        U        pppoe0 fe80::227:eff:fe07:8314%pppoe0    link#7                        UHS        lo0 ff01:1::/32                      fe80::227:eff:fe07:8314%re0  U          re0 ff01:2::/32                      fe80::226:5aff:feeb:55f5%rl0  U          rl0 ff01:3::/32                      ::1                          U          lo0 ff01:7::/32                      fe80::227:eff:fe07:8314%pppoe0 U        pppoe0 ff02::%re0/32                    fe80::227:eff:fe07:8314%re0  U          re0 ff02::%rl0/32                    fe80::226:5aff:feeb:55f5%rl0  U          rl0 ff02::%lo0/32                    ::1                          U          lo0 ff02::%pppoe0/32                  fe80::227:eff:fe07:8314%pppoe0 U        pppoe0 thanks a lot for reply… ;D</up,simplex,multicast></performnud,accept_rtadv></up,pointopoint,running,noarp,simplex,multicast></promisc></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast></full-duplex></performnud,accept_rtadv></vlan_mtu></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_ucast,wol_mcast,wol_magic></up,broadcast,running,simplex,multicast,ipfw_filter>

After banging my head on this for far longer than I should have I realized the problem is that I'm doing this virtual.  My pFsense box is running on Vmware ESXi 5.0.  I didn't realize I needed to set my virtual switch into promiscuous mode in order for bridging to work properly.  After allowing promiscuous mode everything started working great!  Painful lesson learned in terms of time loss so hopefully someone else can avoid it by finding this post.

Use syslog to forward pfsense logs to this Linux box and use the same script on log received. Or use a syslog server That do this sql/frontend for you.

Hallo Nachfalke, Thanks. Now the log is clean. Alfredo.

i wouldn't say it's broken, as it works for every other device than pfsense … directly a laptop instead of pfsense and it works fine and it happened with two boxes already, from two different ISPs edit : another side note I just recalled when this thing happened, when i looked at interfaces status, the wan interface shows a gateway but no ip or subnet the release button is present but no action occurs when pressing it

There's a good chance you're not going to be able to get port 445 over the Internet, a lot of ISPs will block 135-139 and 445 because they're frequently used Windows worm ports, and their most commonly used purpose (Windows SMB and related) isn't something you should do over the Internet. Your default config most likely allows 445 already on LAN rules.

@jimp: patches accepted :-) coolio! :-D

@warhed: I can move to pfSense 2.0.1 but it might have modules that won't work with it, yet, such as BandwidthD bandwidthd works fine, all packages at this point are in much better condition on 2.0.x than 1.2.3, they haven't been maintained on 1.2.3 in ages. @warhed: I setup a rule in pfSense to accept port 44443 and translate that to 443 and to the IP of my Belkin KVM at 192.168.1.15 This does not work. If I change the Belkin KVM IP HTTPS port from 443 to 44443 then I am able to access the unit. Does "PAT"'ing not work with pfSense? of course it works, sounds like you don't know what source ports are (they're random, not the same as the destination), and that you aren't adding port forwards, expecting firewall rules to redirect traffic. http://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F

@marcelloc: The new rules will apply on new connections only. Established connections will continue working or denying. This. That's how every firewall works.

Yes, it did have the correct default gateway configuration, just as the other two. Interestingly enough although it performed normally and was accessible from within the same sub-net, I replaced the unit and the problem appears to be resolved. Logically it made no sense, but it would appear that the hardware did have a problem.

Sorry for the delay, here it is: [image: pfsense.png]

Apparently it's very hard to defend against syn-flood. Check http://forum.pfsense.org/index.php/topic,46897.0.html

Thanks for the quick reply, maybe if I tell you exactly what I'm trying to do you might know another solution. In the gaming forum and actually all across the internet people are having problems with multiple PC's running Battlefield 3 behind the same pfsense router.  Not everyone has this problem.  I dont.  But I'm trying to recreate this problem. I believe it happens in certain setups when PunkBuster on two or more PC's communicate on the same port.  I need to be able to verify this.

Thanks for Help (???) I solved my problem… pfsense uses a configuration file for each interface itself, in this case, the actual file configuration for the interface bridge0 as the startup script: /usr/local/etc/rc.d/snort.sh Look at line 28: /usr/local/bin/snort -R 58154 -D -q -l /var/log/snort --pid-path /var/log/snort/run -G 58154 -c /usr/local/etc/snort/snort_58154_bridge0/snort.conf -i bridge0 We need to edit this file: /usr/local/etc/snort/snort_58154_bridge0/snort.conf To properly monitor traffic on bridge0 we must set two variables in this file correct? **WRONG! VERY WRONG !!! var HOME_NET var EXTERNAL_NET These variables need to be like this: var HOME_NET any var EXTERNAL_NET any But you can not change these parameters directly in the file itself, because it is generated by a script, this script: /usr/local/pkg/snort/snort.inc We need to change this script so that it runs the snort.conf with the correct variables, here we go: In the file /usr/local/pkg/snort/ snort.inc line 233 change: $ HOME_NET = "[{$ HOME_NET}]"; to: $ HOME_NET = "any"; And the line 1330 change: $ EXTERNAL_NET =! '$ HOME_NET'; to: $ EXTERNAL_NET = 'any'; Save file! Now the last set, edit the file: /usr/local/etc/snort/snort_58154_bridge0/snort.conf In session: preprocessor sfportscan: scan_type {all}                          proto {all}                          memcap {10000000}                          sense_level medium} {                         ignore_scanners HOME_NET $ {} Review the option ignore_scanners {$ HOME_NET}: preprocessor sfportscan: scan_type {all}                          proto {all}                          memcap {10000000}                          sense_level {medium}                         #ignore_scanners HOME_NET $ {} Save the file, go snort services and restart the interface and everything works beautiful! Thanks for Help (???) …..  :-X ::) >:(**

UDP and ICMP have no concept of "connections" the way TCP does. If a source sends 50 pings to one destination it's all one "connection". If a UDP client sends 50 packets using the same source and destination ip:ports, it's one connection. Make sure that your testing accounts for that and you should have better results. (or try tcp). Other than that, seeing a copy of your /tmp/rules.debug might help see what's going on.

Either way might get complicated. I personally prefer NAT reflection over split horizon DNS, as johnpoz suggested.