What is the biggest attack in GBPS you stopped
-
Make sure you know exactly which drivers are loading up to support the interface. Some commands to run in FreeBSD to help:
[b]pciconf -lv[/b]em0@pci0:0:25:0: class=0x020000 card=0x20448086 chip=0x15038086 rev=0x04 hdr=0x00
class = network
subclass = ethernetThe usb nics are not visible only the USB hubs they are plugged into.
That will list the interfaces and classify them for you. Also go to /var/log/dmesg.boot to see your last boot log. You'll see a section in there that will look something like this:
Motherboard nic
em0: <intel(r) 1000="" pro="" network="" connection="" 7.4.2="">port 0xf080-0xf09f mem 0xf7c00000-0xf7c1ffff,0xf7c29000-0xf7c29fff irq 20 at device 25.0 on pci0
em0: Using an MSI interruptUsb nics ue0 to ue3 same as below have not plugged in the gigabit ones yet.
ukphy0: <generic ieee="" 802.3u="" media="" interface="">PHY 16 on miibus0
ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0: <usb ethernet="">on axe0And of course the ever popular ifconfig.
FreeBSD loads NIC drivers (I think) from the kernel, so it might take some hunting to determine which ones are being used.
em0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=4209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso>ether
inet6 em0 prefixlen 64 scopeid 0x1
inet 192.168.37.1 netmask 0xffffff00 broadcast 192.168.37.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
ue0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=80008 <vlan_mtu,linkstate>ether
inet6 ue0 prefixlen 64 scopeid 0x6
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
ue1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=80008 <vlan_mtu,linkstate>ether
inet6 ue1 prefixlen 64 scopeid 0x7
inet 192.168.60.1 netmask 0xffffff00 broadcast 192.168.60.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
ue2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=80008 <vlan_mtu,linkstate>ether
inet6 ue2 prefixlen 64 scopeid 0x8
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
ue3: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=80008 <vlan_mtu,linkstate>ether
inet6 ue3 prefixlen 64 scopeid 0x9
inet 192.168.50.50 netmask 0xffffff00 broadcast 192.168.50.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
status: activeIf you need any other info let me know.
Supermule if you want to hit me up, my ip is currently 92.29.124.124, VMware is recording the dashboard so traffic graphs for the interfaces, system activity and Status: System logs: Firewall (Dynamic View), with packet capture running on wan. Current CPUP load is 41 as if with nothing really happening other than those browser windows running along with snort so off to make a cup of tea. ;)</full-duplex></performnud,auto_linklocal></vlan_mtu,linkstate></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud,auto_linklocal></vlan_mtu,linkstate></up,broadcast,running,simplex,multicast></full-duplex></performnud,auto_linklocal></vlan_mtu,linkstate></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud,auto_linklocal></vlan_mtu,linkstate></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso></up,broadcast,running,promisc,simplex,multicast></usb></generic></intel(r)>
-
Oh and whilst I remember, the wan interface is currently one of the USB nics, the EM0 (Intel nic) using the same drivers as you guys reporting problems is the lan interface so this first test will in effect be a driver test before I swap the wan on the EM0 nic.
-
Hitting you up on port 80 :)
Is it pingable and NAT'ing to something behind it?
-
You can stop it now for that ip address as I'm on another one.
I dont think it was pingable we could for the next test make it pingable but the problem with ADSL is its faster down than up so you may not get consistent pings back anyway.
When you say NAT'able what do you mean by that?
I tried a variety of different settings throughout, like trying to access ip addresses that were closer to me than the ip addresses coming in to port 80, swapped the firewall optimisation around from aggressive to normal to high latency (satellite links) whilst trying to get out but no joy at getting any webpages up throughout, the odd DNS request packet got out seen as a green icon in the dynamic fw log.
Interestingly it seemed to max out at 2.42Mbps yet various speed tests suggest I have a 5Mbps adsl connection. CPU was 100% through out.
FW stayed responsive throughout with snort running, changing various rules made some of the dashboard interface graphs stop updating second by second to maybe updating 10seconds later but I get that anyway when updating some rules or changing things in snort.
The only time I managed to kill the fw was trying to load the RRD graphs for All just a moment ago with the other fw webpages (dashboard, system activity, dynamic fw log) opened along with one or two other fw webpages open when changing rules etc, otherwise I'd have stayed on the old ip address for longer trying different things.
I got to pop out for an hour or so now, but when I get back we can try swapping the USB nic currently handling the wan interface over to the motherboards built in intel nic (em0) to test the driver theory next if you want?
It was funny because this song below was playing in my head throughout the test when I popped my head in to look at the fw as I was cooking some breakfast and eating it at the same time. ;)
www.youtube.com/watch?v=ZHwVBirqD2s
Edit. I could put one of the webservers I have written up if you want port 80 open, but I'd need to load up the relevant vm which I programmed it on and I have hundreds of vm's to go through as I'm in the processes of getting rid of old one's copying necessary code off them where applicable and generally consolidating them which is a lengthy process as I need to make sure I havent missed any source code, dll's, icons, images, help files, etc etc before deleting the vm.
-
No worries mate. Let me know when youre ready. :)
-
The only time I managed to kill the fw was trying to load the RRD graphs for All just a moment ago with the other fw webpages (dashboard, system activity, dynamic fw log) opened along with one or two other fw webpages open when changing rules etc, otherwise I'd have stayed on the old ip address for longer trying different things.
Something to note: When emX runs out of stated the entire pfSense device becomes sluggish. When you increase the states to over 5M, the emX interface goes down but the pfSense box is unaffected.
The console will show the state table getting filled in the first example and during the second test you may see the IRQ interrupt storm. I strongly recommend having the console open during testing because you'll get much more tangible information during testing. I sent almabes a ton of performance links and FreeBSD commands yesterday that should really help. I'm giving him time to digest them and eventually post them.
-
Ran 8M states and it performed well during the tests when it stayed up.
I dont see interrupt storms on the console. I have had a kernel taskq on the core that rises to 100% usage and then packet loss.
-
This is one of the links I sent out last night. http://bsdrp.net/documentation/technical_docs/performance
Use this more for the monitoring tools and the data they capture. It should help immensely. You may have to modify pfSense as some of the tools/modules may not be loaded by default in the distribution. You can grab them from FreeBSD as noted in the article.
-
I've been thinking about this, considering it was the RRD graphs which took out my fw straight away, I dont think the drivers are the issue really but more the SMP support in freebsd 10.1 like Harvy66 mentions in the FreeBSD 11 thread and in post 14 on this thread.
One way I can test this theory is to fire up an old single core AMD laptop with the same usb nics on the wan and see how it performs.
Laptop spec is not identical admittedly to the intel D847 ie only 2 or 4Gb of ram, spin disk instead of msata, but the nics will be the same as will pfsense.
Failing that, if I can get pfsense running on the raspberry pi's I have here, I can test on a RPi1 b (single core) as well as the new RPi2 which is quad core but same 1Ghz, same ram and will have same usb nics although the Arm cpu instruction sets are different.
Worth trying the single core laptop next instead?
-
Just let me know :)
-
Current IP address is 92.28.255.154
I've created an allow ICMP (ping) rule through to the wan so can you give it some pings first, then when I say we can test the EMx intel nic whilst I dust off this laptop at the same time.
I'm not going to attempt accessing the RRD graphs again for now, but everything else will be as before ie
dashboard running, system activity window, dynamic fw logs running along with me navigating around the fw changing rules etc to check responsiveness is still there.Edit. Can you let us know when you have done the pings as I have not seen anything yet.
-
It says no answer to ping here…
-
You can stop it now, I've changed ip address and I hadnt swapped the cables over.
Let me check the rules as I can see one ICMP came in which was allowed but I wasnt sure if that was you or anyone else reading the thread pinging me.
I also found a crash report from lunch time which I'll be submitting but it looks like the fw ran out of memory around the time I tried loading the RRD graphs.
Edit. Give me a few minutes as Unbound (the default DNS server setup in 2.2) doesnt like running with Firewall Optimisation (state timeouts) set to aggressive ie it timeouts the states quickly before the various name servers get a chance to respond when the fw reboots. I've swapped it over to High Latency for now and will leave it on that for the duration of the tests, but if unbound is running when the fw reboots and the state timeouts is too short, that will screw you over as well.
-
Feel free to post findings :)
-
Are you sure the ICMP isnt working as it was around 15:00 BST (14:00 UTC) I saw the single ICMP packet come in?
What time did you do an ICMP test? Try it now and I'll keep an eye out on the logs as theres no traffic going out except when I refresh the forum webpages.
Edit : I can see one ping come in just a moment ago from an ip address .94, so is that you SM, if so I'll swap the cables over to test the EMx intel nic on the fw.
-
Mine is 80.197.148.74 right now :)
I am pinging 92.28.255.154 and requests is timing out
-
92.28.252.160
-
Reply :)
Should I hit that one?
-
Hold off for a moment as something screwing is going on with the fw rules (PF) at the moment, but I got a brief DDOS if that was you but no ICMP showed up in the fw logs from your ip address.
I need to check out whats going on with the fw rules as something isnt right this end so I'm going to reboot as resetting all states didnt reset the rules surprisingly.
edit.
The logs run about 2mins behind on this fw so any change I make and reset of states takes a few minutes longer before I can confirm its ok in the log. -
Ready?