Re: [pfSense Support] 2 networks on the LAN interface, vlan, trunk?
Ugo Bellavance wrote: VLAN 101 contains ports that are connected directly to the internet (PfSense WAN port, internet port (it is in colocation), other servers that would be connected directly to the internet (not behind PfSense). VLAN 102 contains ports that are connected to devices in the Subnet1, let's say 10.10.10.0/24. VLAN 103 contains ports that are connected to devices in the Subnet2, let's say 192.168.10.0/24. this seems OK, I think, once you've created vlans you assign the wan and lan ports appropriately, then make vlan103 be say OPT1 (and rename it to LAN2?) However, subnet2 is completely isolated. It cannot talk to anyone, nor to the fw, nor the subnet1, nor the internet. if you manually add static routes to hosts on vlan103, does it work? what are you seeing in the arp tables on the hosts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Small correction for script tools/builder_scripts/cvsup_current
Attached is a patch with a couple 'cutpaste' typos corrections, plus a
conditional for not installing fastest_cvsup if you have set
OVERRIDE_FREEBSD_CVSUP_HOST
Hope this can be included in the repository.
Angelo Turetta
Modena - Italy
Index: cvsup_current
===
RCS file: /home/pfsense/cvsroot/tools/builder_scripts/cvsup_current,v
retrieving revision 1.164
diff -u -r1.164 cvsup_current
--- cvsup_current 12 Sep 2007 15:56:57 - 1.164
+++ cvsup_current 27 Sep 2007 14:58:37 -
@@ -81,16 +81,18 @@
env FTP_PASSIVE_MODE=yes /usr/sbin/pkg_add -r cvsup-without-gui
fi
+if [ -z ${OVERRIDE_FREEBSD_CVSUP_HOST:-} ]; then
# Add fastest-cvsup
if [ ! -f /usr/local/bin/fastest_cvsup ]; then
- echo Cannot find cvsup, pkg_add in progress...
+ echo Cannot find fastest_cvsup, pkg_add in progress...
/usr/sbin/pkg_add -r fastest_cvsup
fi
# Failed, lets try with passive mode
if [ ! -f /usr/local/bin/fastest_cvsup ]; then
- echo Cannot find cvsup, pkg_add in progress (PASSIVE FTP)...
+ echo Cannot find fastest_cvsup, pkg_add in progress (PASSIVE FTP)...
env FTP_PASSIVE_MODE=yes /usr/sbin/pkg_add -r fastest_cvsup
fi
+fi
# Add pcre
if [ ! -f /usr/local/lib/libpcre.so.0 ]; then
@@ -114,7 +116,7 @@
env FTP_PASSIVE_MODE=yes /usr/sbin/pkg_add -r lighttpd
fi
-# Add cvsup
+# Add curl
if [ ! -f /usr/local/bin/curl ]; then
echo Cannot find curl, pkg_add in progress...
/usr/sbin/pkg_add -r curl
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Issue with stalling on static route
check the box to bypass firewall rules for traffic leaving the same interface it enters on the Advanced page. This seems to have fixed it. Odd that there were no entries in the firewall logs about blocking traffic... and how it was so erratic. Thanks for the help! James- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Small correction for script tools/builder_scripts/cvsup_current
On 9/27/07, Angelo Turetta [EMAIL PROTECTED] wrote:
Attached is a patch with a couple 'cutpaste' typos corrections, plus a
conditional for not installing fastest_cvsup if you have set
OVERRIDE_FREEBSD_CVSUP_HOST
Hope this can be included in the repository.
Angelo Turetta
Modena - Italy
Index: cvsup_current
===
RCS file: /home/pfsense/cvsroot/tools/builder_scripts/cvsup_current,v
retrieving revision 1.164
diff -u -r1.164 cvsup_current
--- cvsup_current 12 Sep 2007 15:56:57 - 1.164
+++ cvsup_current 27 Sep 2007 14:58:37 -
@@ -81,16 +81,18 @@
env FTP_PASSIVE_MODE=yes /usr/sbin/pkg_add -r cvsup-without-gui
fi
+if [ -z ${OVERRIDE_FREEBSD_CVSUP_HOST:-} ]; then
# Add fastest-cvsup
if [ ! -f /usr/local/bin/fastest_cvsup ]; then
- echo Cannot find cvsup, pkg_add in progress...
+ echo Cannot find fastest_cvsup, pkg_add in progress...
/usr/sbin/pkg_add -r fastest_cvsup
fi
# Failed, lets try with passive mode
if [ ! -f /usr/local/bin/fastest_cvsup ]; then
- echo Cannot find cvsup, pkg_add in progress (PASSIVE FTP)...
+ echo Cannot find fastest_cvsup, pkg_add in progress (PASSIVE FTP)...
env FTP_PASSIVE_MODE=yes /usr/sbin/pkg_add -r fastest_cvsup
fi
+fi
# Add pcre
if [ ! -f /usr/local/lib/libpcre.so.0 ]; then
@@ -114,7 +116,7 @@
env FTP_PASSIVE_MODE=yes /usr/sbin/pkg_add -r lighttpd
fi
-# Add cvsup
+# Add curl
if [ ! -f /usr/local/bin/curl ]; then
echo Cannot find curl, pkg_add in progress...
/usr/sbin/pkg_add -r curl
Commited, thanks!
Scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Poor DNS performances and websurfing...
Hello, In the last week I noticed poor DNS performances and obviously web surfing suffers, too. This is the output from a PC configured to use the IP address of the main pfSense machine: $time nslookup www.google.com nslookup can take from 0.022s to 5.004s or even 10.04s! I have to click twice or three times a link in a web page to successfully connect to it without timeout error. Bandwidth from the ISP seems to be OK. I noticed if a PC download near at the max speed from a HTTP page, DNS performance becomes worst. I didn't experience this behaviour in the previous release of pfSense. Previous one seemed to handle better a high load. Maybe a re-installation of pfSense (1.2RC2) can improve this situation or some network settings have been changed in the latest release? Notice that no P2P programs were or are running. I heard about BIND: does pfSense already offer its features? I've a further question to pfSense's developer about the 'at' command: is it broken in the 1.2RC-2 version (see message entitled: How to schedule shutdown and box heartbeat)? Thanks. ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] Poor DNS performances and websurfing...
Am 27.09.2007 um 23:17 schrieb tester: Hello, In the last week I noticed poor DNS performances and obviously web surfing suffers, too. This is the output from a PC configured to use the IP address of the main pfSense machine: What DNS-servers did the pfsense get from the ISP? Do they work? Could it be that one of them is dead? Try with [EMAIL PROTECTED] www.somedomainyouvenotcheckedbefore.com and [EMAIL PROTECTED] www.someotherdomain.com cheers, Rainer -- Rainer Duffner CISSP, LPI, MCSE [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] Poor DNS performances and websurfing...
And just for the sake of trying... give opendns.com a shot. -Tim -Original Message- From: Rainer Duffner [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 3:18 PM To: support@pfsense.com Subject: Re: [pfSense Support] Poor DNS performances and websurfing... Am 27.09.2007 um 23:17 schrieb tester: Hello, In the last week I noticed poor DNS performances and obviously web surfing suffers, too. This is the output from a PC configured to use the IP address of the main pfSense machine: What DNS-servers did the pfsense get from the ISP? Do they work? Could it be that one of them is dead? Try with [EMAIL PROTECTED] www.somedomainyouvenotcheckedbefore.com and [EMAIL PROTECTED] www.someotherdomain.com cheers, Rainer -- Rainer Duffner CISSP, LPI, MCSE [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: [pfSense Support] Poor DNS performances and websurfing...
Perhaps you should try to use the traffic shaper to give dns a higher priority... It's running in this constellation at all my systems and it's running fine... It's obvious that when the wan-pipe is heavily loaded, dns packets have to wait if there's not qos... -Ursprüngliche Nachricht- Von: tester [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 27. September 2007 23:18 An: support@pfsense.com Betreff: [pfSense Support] Poor DNS performances and websurfing... Hello, In the last week I noticed poor DNS performances and obviously web surfing suffers, too. This is the output from a PC configured to use the IP address of the main pfSense machine: $time nslookup www.google.com nslookup can take from 0.022s to 5.004s or even 10.04s! I have to click twice or three times a link in a web page to successfully connect to it without timeout error. Bandwidth from the ISP seems to be OK. I noticed if a PC download near at the max speed from a HTTP page, DNS performance becomes worst. I didn't experience this behaviour in the previous release of pfSense. Previous one seemed to handle better a high load. Maybe a re-installation of pfSense (1.2RC2) can improve this situation or some network settings have been changed in the latest release? Notice that no P2P programs were or are running. I heard about BIND: does pfSense already offer its features? I've a further question to pfSense's developer about the 'at' command: is it broken in the 1.2RC-2 version (see message entitled: How to schedule shutdown and box heartbeat)? Thanks. ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] Adding new NIC drivers
I figured this out by adding if_myk_load=YES to /boot/loader.conf. I don't know if this is where it's supposed to go, but it works. Now the million-dollar question: can I do a firmware upgrade without loosing this entry in the /boot/loader.conf? I'm confident the .ko files I copied to /boot/kernel won't get deleted during updates, but I want to make sure that the /boot/loader.conf doesn't get overwritten. Otherwise, I'll have a bunch of pissed off clients and a trip to our colocation on my next update. :) --Bennett Bennett Lee wrote: OK, after many problems, like couldn't install because of no known NICs, installing NICs in a 1U case with no riser, figuring out how to mount, if_myk.ko requiring libmbpool.ko, etc., I finally got the drivers installed with kldload and they appear to work. Until I rebooted. The drivers don't reload. What to do I need to change in order to get them to install permanently? --Bennett Bill Marquette wrote: Probably easiest to load them onto a USB keyfob and mount it after boot. Then kldload the if_myk.ko module. --Bill On 9/25/07, Bennett Lee [EMAIL PROTECTED] wrote: I've got a new motherboard with quad-GB LANs that all use Marvell 8056, which isn't supported by pfSense/FreeBSD. I d/l Marvell's Yukon FreeBSD drivers, which supposedly support this board. Their .tgz contains if_myk.ko, +CONTENTS, and myk.4.gz. Inside myk.4.gz is myk.4. How do I add these drivers to the LiveCD so I can try them out? Is it as easy as injecting the files into the CD into some particular folder and maybe adding them to a boot config file? (I hope so--haven't done anything in *nix since I wrote a crappy little client/server app back in college [many, many, many] years ago.) --Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] jabber and NAT woes
Will Miles wrote: Hi, I ran in to this one too. The basic issue is that jabber leaves its TCP connection open but idle when there's no actual messaging traffic going on, and pfSense's scheme to implement NAT reflection (ie. accessing the public IP address from the LAN) depends on the use of a TCP proxy that has a fixed timeout (although IIRC there's currently a hidden option that allows adjusting the specific timeout). In this case adjusting the state timeout won't help because it's not the state table that's timing out - it's the TCP proxy. The quickest fix is to use the DNS proxy on your pfSense box and set a fixed mapping of the external name to the internal IP of the server. This forces the internal client boxes to connect directly, and still allows external clients to operate normally through the firewall (since they resolve DNS against the public DNS servers that carry the correct external IP). Another fix is to adjust the TCP proxy timeout - I'm not sure where that lives currently, although IIRC it's not accessible from the GUI; the details are in the forums somewhere. Unfortunately, this can lead to dead proxy processes kicking around on your pfSense box for long periods of time before they time out, but at least the live connections don't go with them. The Linux kernel supports doing NAT reflection directly in the kernel, which is why it 'just works' with IPCop. Unfortunately, the FreeBSD gurus claim that their NAT system is not capable of doing this within the packet filtering framework. That said, it /is/ possible to trick it into behaving this way, and I assembled a patch for my own usage to solve this specific problem, but since the experts claim it's not possible there's no guarantee it will behave correctly in all circumstances. I'll see if I can get it together over the weekend - I'm still using one of the 1.2 betas, though, so it'd take me a bit to update it for the RC build. That said, it doesn't remove the proxy-based reflection scheme, so if you're interested in the patch you can always go back to whichever model you find works best for you. -Will Miles Thanks for the detailed explanation Will. We'll try adjusting the tcp proxy timeout. I think we found some sort of timeout setting we tried to set in the config file, but I'm not sure it was the tcp proxy timeout. And when we tried it, we hand hacked the xml, and broke the syntax (didn't close a tag), which confused us. We've reverted to IPcop until we can schedule another maintenance window to sort this out. Cheers -- Geoff Crompton Debian System Administrator http://www.strategicdata.com.au Phone: +61 3 9340 9000 Fax: +61 3 9348 2015 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] disable console menu
Two small remarks on the disable console menu option in the miscellaneous subsection of the system - advanced page (1.2-RC2). Nothing serious; only cosmetic issues. 1. The page says Changes to this option will take effect after a reboot. This is not the case; changes take effect immediately. I would suggest to remove this remark in a future release. 2. I was a bit surprised about the effect of this option: the console menu is not at all disabled, but a login is required before it is displayed. I would suggest to change the options title in a future release. I like this option: it increases security and saves a job running. Furthermore, the it saves those false alarm messages in the system log (root login on console), when the menu refreshes a few times a day. Of course it should not be used by people who forget passwords.;-) regards, Jan Hoevers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
