Problem solved with update.

If you don't do layer3 routing on your cisco just connect a trunk of tagged vlans to pfsense, configure the vlans on the parent physical interface and create one interface for every vlan. Assign ip according to your subnets.

So your saying your not seeing gig?  Do you have gig wan?  Unless your wan is gig and your only seeing like 800 or something I don't see what your trying to squeeze out here?

you got some sort of asymmetrical issue if your not seeing the full handshake and then traffic would be my guess. Setting state to sloppy is not something you should have to do. Can you layout your connectivity - how many vswitches?  How many physical interfaces - what is the setting do you have on the vswitch that has tagged vlans?

I tried with Group ACL method but not able to block for single IP or network. Then you're doing something wrong.  It does work.  I use it that way myself.  Maybe you have a problem with the order the ACLs are listed in? btw this really should be in the Cache/Proxy forum.

My fault. They were already instaled  :o ;D

The SCP permission works just fine with 2.3.3 and later. Of course if you don't have permissions to the directory or files as that user, you won't be able to download files from there.

Eh? What client where? LAN => LAN does not go through the firewall.

U should be able add your whole lan net to allow remote admin but why?

Doing OTP via LDAP/RADIUS isn't really that feasible for what we are looking at. I mean it isn't impossible, but not really something I'd like to pursue. I would encourage you to consider adding this, if feasible, as it is a nice security feature. A full implementation that integrates with AD and does enterprise certificate authentication would be cool, but that aside just something simple like SSH keys could work well. Just have the ability to add a public certificate for a user and then do a CAPI auth for that. Requires manually updating certificates and so on but gives people the ability to do 2-factor without needing an enterprise PKI setup. Just a Yubikey (or anything like it) and you are good. The SSH idea is one I may try. It will work fine, Putty-CAC works great with Yubikeys and will give you an SSH key that works properly and requests the right CAPI certificate. So it would work in that card+pin would be needed to access the system. I'll think about that and how much that gets us over just having Webadmin access restricted to a particular set of systems, which require card+pin anyhow.

Thanks for the tip.  I just checked the pfSense book and it doesn't go into much detail at all about URL aliases and URL tables aliases. I did misspeak earlier.  You should be using an URL alias, not URL Table.  URL Table is for when the list needs to be updated on a schedule.

1. Update. 2.1 is ancient and that rate bug was fixed a long time ago. 2. Limiters do not use Rate. 3. It is safe to kill rate, it is only used to provide per-host bandwidth stats on Status > Traffic Graphs

@whorfin: @whorfin: ngrep and socat, please Just grabbing these did seem to work: http://pkg.freebsd.org/freebsd:10:x86:64/release_3/All/ngrep-1.45_3.txz http://pkg.freebsd.org/freebsd:10:x86:64/release_3/All/socat-1.7.3.1.txz Please add tcpflow; this is particularly relevant as the version on freebsd.org requires cairo, which is a dealbreaker in embedded context. There is no option on the port to compile it without cairo. If we added it, it would also use cairo. The FreeBSD port maintainer should add an option to the port to disable cairo ("–enable-cairo=false" when running configure) and then we could set it to build without cairo in our repo. I liked tcpflow before it gained the cairo bloat. I haven't used it in years though. @s0rcier: can u please add murmur package… small mumble voice server... thanks I don't see us adding anything like that. That sort of service does not belong on a firewall.

Clients will typically request the address they had before when connecting to a network. It doesn't mean there is a problem, since they will get rejected and then send a new request to get a new address. It's a common behavior for DHCP clients to want to keep the same address if possible. Now if they actually obtained an address for the wrong network, then you might have some cause to worry since it means you have an L2 connection between the segments so they're actually on the same switch segment which isn't what you want. That doesn't appear to be the case from what little you've shown in the log at least.

Traffic from the firewall itself won't use the IPsec tunnel unless it matches the IPsec P2. Since IPsec is not routed, the firewall does not know well enough on its own that it needs to source the traffic in a special way in order to use the tunnel. https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN