Ipguard package
-
I've gotta be doing something wrong… I can't seem to get Ipguard working for what I want. This is what is in my /usr/local/etc/ipguard_lan.conf
00:e0:52:c2:e0:c4 192.168.5.1 pfsense LAN interface
00:25:ae:28:38:a9 192.168.5.200 XBox-Wired
00:0d:4b:bd:d1:61 192.168.5.201 roku-basement
00:0d:4b:df:c1:3d 192.168.5.202 roku-den
cc:6d:a0:1f:a5:11 192.168.5.203 roku-family-rm
00:0d:4b:e8:1e:59 192.168.5.204 roku-master-bdrm
00:13:72:98:dc:2b 192.168.5.205 rjc-nas
00:22:58:7b:85:97 192.168.5.206 Brother-MFC-J430W
00:00:00:00:00:00 192.168.5.0/24 lan netI'm trying to set it up so that no MAC other than those listed above can use the 200-207 IP addresses on my network and get out to the internet - but to no avail. I can set my laptop to 206 address (Brother-MFC-J430W listed above) and it seems to have no affect whatsoever. I can browse the internet, etc. What am I doing wrong?
Additional info about my setup... I'm using Squid and Dansguardian. The reason I'm trying to stop other MAC's from taking the 200-207 addresses is that 192.168.5.200/29 is allowed out without going through Dans (I have firewall rules that block all other addresses from hitting the internet directly).
Thanks for any help!
I ended up solving my problem by writing a little shell script that executes tcpdump looking for packets with sources range 192.168.5.200/29. It then compares the MAC address on each packet to a list of valid MAC/IP pairs. If a mismatch is found, it shuts down the WAN interface (assumption being a rogue MAC has taken one of my unfiltered IP addresses)! A little draconian, but effective. Added a startup/shutdown script for it and it accomplishes what I want…
However - I thought I could accomplish the same thing with ipguard... can anyone tell me? Thanks!
-
Bump…
Not a big deal because I got it working with the tcpdump shell script, but I'm still wondering if my use case was valid for ipguard? i.e. should I be able to make ipguard work to block invalid mac/ip combos from accessing the internet?
Anyone? Thanks...
-
try to reduce your network range on your allow list and move pfsense ip to 254 for example.
00:e0:52:c2:e0:c4 192.168.5.254 pfsense LAN interface
.
.
.
00:00:00:00:00:00 192.168.5.0/25 lan net -
OK… seems like I tried that, but I will play around with it some more... Before I do though, I just want to confirm. What I'm trying to do is what ipguard was intended to accomplish? i.e. make sure that ip/mac combinations (or ranges) are valid and keep invalid combos from accessing network resources?
Also (again I'll play more to confirm) I turned on the verbose logging and from what I could tell, it appeared that ipguard was catching the invalid mac/ip combination and returning the bogus mac address on the ARP request/reply. However, everything still worked for the IP address involved. It shouldn't... correct?
Thanks again...
-
On my tests, it was easier to lost access to pfsense then full access.
Maybe your 00:00:00:00:00:00 192.168.5.0/24 ipguard lan net rule permits all lan access.
-
This package seems to not work correctly with: 2.1-BETA0 (amd64).
After installing the package there is no addition of Ipguard to the services drop down menu.
-
It's on firewall menu ;)
I'm not sure if I tested it's dirs and pbi install on 2.1
-
I have ipguard-dev installed on 2.1-BETA0. It puts a link to its exe into /usr/local/sbin, so the package startup code works fine as is.
[2.1-BETA0][root@pfsense.localdomain]/(8): ls -l /usr/local/sbin/ipguard lrwxr-xr-x 1 root wheel 35 Oct 8 19:06 /usr/local/sbin/ipguard -> /usr/pbi/ipguard-i386/.sbin/ipguardThe 2.1, FreeBSD 8.3, pbi-based package version is working.
-
I'll include pfsense 2.1 folder check as soon as possible…
-
@marcelloc - I don't think any folder/version checks are needed. The PBI installation puts the link to the exe in /usr/local/sbin already - so running /usr/local/sbin/ipguard works on 2.1. The conf file goes in /usr/local/etc fine. I think it all works out of the same folders in 2.0.1 and 2.1.
-
I think it all works out of the same folders in 2.0.1 and 2.1.
good! Thank's for the info. :)
-
i installed ipguard on pfsense 2.01 32bit, when i click on the start button in the Services menu it just doesnt start. There is a message saying it started but in the menu it keeps being stopped. Is there a way to start it manually (command line) or see the logs for when a service start?
-
Check your config first and save settings. Then go to console and check if its running with "PS ax "
-
nope not running
EDIT:I accessed pfsense in ssh and when I try to launch ip guard it says this:
/libexec/ld-elf.so.1: Shared object "libpcap.so.1" not found, required by "ipguard"
-
what version of pfsense are you running?
-
2.0.1-RELEASE (i386)
i fixed this issue by installing snort, which installed the missing dependencies but now i've got another problem
in /var/log/ipguard_fxp0.log i get:
error pcap_open_live(): fxp0: No such device exists (BIOCSETIF failed: Device not configured) -
I've tested this package without snort without issues, I'll try it again on virtual lab.
-
Hey there guys,
Here's the problem I'm running into and I'm hoping ipguard can turn the trick….
I have a wifi client who for whatever reason is always trying to set a static IP that conflicts with an ip address in my static range, which causes temporary problems from time to time.
I'd like to make sure that these addresses are not in conflict in situations like this. Since my static devices are all known and well documented, would the correct approach be to enter them all in ipguard, thereby (hopefully, I think?) ensuring that no other mac address can inadvertently obtain access to my LAN (wifi) using a reserved, static ip?
???
-
Sure, ipguard can help.
Did you tried static mapping on pfSense dhcp+ Deny unknown clients?
-
Surge, ipguard can help.
Did you tried static mapping on pfSense dhcp+ Deny unknown clients?
No, and here's why: I run a WISP and I don't want to deny unknown clients. They can sign up online thru the captive portal and that's $$ ;D
However, I did try mapping it to an IP address, but pfSense tells me that I can't do that inside of the dynamic IP range….. which seems silly, actually.
