[pfSense Support] Registration open for pfSense training at BSDCan!

2008-03-22 Thread Chris Buechler

Please see the following post for more information.

http://blog.pfsense.org/?p=182

Hope to see you there!

Chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [pfSense Support] Captive Portal

2008-03-22 Thread Dimitri Rodis
If I made the modifications to display the mac/client IP on the
"default" captive portal page, would you commit it and make it the
default captive portal page? I would just throw a couple of lines right
beneath the login button that say: 
Client MAC: xx:xx:xx:xx:xx:xx
Client IP: xxx.xxx.xxx.xxx

Dimitri Rodis
Integrita Systems LLC 


-Original Message-
From: Chris Buechler [mailto:[EMAIL PROTECTED] 
Sent: Saturday, March 22, 2008 6:41 PM
To: support@pfsense.com
Subject: Re: [pfSense Support] Captive Portal

Dimitri Rodis wrote:
>
> If I wanted to display a user's IP address AND MAC address on the 
> captive portal page, does anyone have a code snippet that would do 
> that on the pfSense captive portal page? Is this possible?
>

I suggest opening a feature request ticket on cvstrac.pfsense.org, 
and/or starting a bounty. Somebody would probably be willing to pick 
this up for relatively cheap.


-
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] Single Captive Portal Login Triggers Dual Accounting Sessions

2008-03-22 Thread Chris Buechler

Kelvin Chiang wrote:
Hi, I am seeing a phenomenon, that a single captive portal login 
triggered 2 accounting sessions, did anyone see this before?


Not that I've heard of. If it's something you can consistently 
replicate, please open a ticket at cvstrac.pfsense.org.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] Captive Portal

2008-03-22 Thread Chris Buechler

Dimitri Rodis wrote:


If I wanted to display a user’s IP address AND MAC address on the 
captive portal page, does anyone have a code snippet that would do 
that on the pfSense captive portal page? Is this possible?




I suggest opening a feature request ticket on cvstrac.pfsense.org, 
and/or starting a bounty. Somebody would probably be willing to pick 
this up for relatively cheap.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] unexpected network throughput

2008-03-22 Thread Chris Buechler

Eric Baenen wrote:
As I said before - all is working fine - except:  when doing rsync's 
over ssh/scp from the lab machines to the services core, I'm seeing a 
maximum sustained throughput of around 60Mbps.  With gigabit end to 
end - even with the AES encryption overhead of the OpenVPN connection 
and the scp encryption overhead of the file transfer, I would have 
expected higher throughput than this.  The sending machines and the 
receiving server are not showing high CPU load so I don't think the 
encryption is the issue.


What do you get using a faster protocol, like FTP?  Not sure about rsync 
over SSH, but SCP is a terrible protocol when it comes to speed, and 
this might be similar. Trying something else should help narrow down 
where the issue lies.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [pfSense Support] unexpected network throughput

2008-03-22 Thread Joel Robison
Just a thought,  you may want to try using '-c blowfish' on your scp/ 
rsync transfer.  It is a faster and lighter cypher.  It may not help  
at all, but it would be interesting as a test.


-Joel

On Mar 22, 2008, at 5:22 PM, Eric Baenen wrote:


Hello,

I'm very new to pfSense, but I am very impressed.  I've installed it  
in my environment and everything is working except I'm getting less  
network throughput than I would have expected and was just wondering  
if anyone might have some insight into why.


My setup and use of pfSense is admittedly out of the ordinary but it  
does seem to be working fine.


I have 8 laboratory facilities on a campus interconnected with a  
flat gigabit ethernet standalone backbone (ie. no external access).   
Each of the laboratories is firewalled off from each other (pfSense  
firewalls) but maintains a permanent OpenVPN based VPN connection to  
a centralized 'core' of services (Zimbra for lab-to-lab email/ 
webmail, OpenFire jabber IM server, Apache/TikiWiki web/ 
collaboration, BackupPC centralized backup server, centralized file  
server, OSSIM security monitor, etc.).  In the near future we will  
configure individual lab to lab VPN connections to facilitate  
collaboration, resource sharing, etc.


Seven of the labs connected have the following setup.

lab machines/servers - lab gigabit switch - pfSense firewall -  
backbone gigabit switch


The pfSense firewalls are all Dell 2.6GHz GX270's with 512MB RAM, an  
on-board gigabit port, and a second Intel Pro 1000 gigabit NIC.   
Both ports in each of the firewalls appear to be running at 1000base  
full duplex


The 8th lab setup is a bit goofy - it's not currently connected and  
will be the subject of a follow up email to this list.


The VPN connections from each lab to the core are OpenVPN, UDP,  
shared key, AES 128bit (for now), LZO compression enabled.


Each lab network is on a unique IP space - for example:

Lab 1: 192.168.10.0/24
Lab 2: 192.168.15.0/24
Lab 3: 192.168.20.0/24
Lab 4: 192.168.25.0/24
Lab 5: 192.168.30.0/24
Lab 6: 192.168.35.0/24
Lab 7: 192.168.40.0/24

Core: 192.168.250.0/24

I'm not sure if this is the right, best or most efficient way to set  
up the VPN's but based on the instructions on the pfSense site I set  
up a separate OpenVPN tunnel for each lab...


Lab 1: port 1191 on the Core pfSense firewall (vpn subnet:  
192.168.249.0/24)
Lab 2: port 1192 on the Core pfSense firewall (vpn subnet:  
192.168.248.0/24)
Lab 3: port 1193 on the Core pfSense firewall (vpn subnet:  
192.168.247.0/24)
Lab 4: port 1194 on the Core pfSense firewall (vpn subnet:  
192.168.246.0/24)
Lab 5: port 1195 on the Core pfSense firewall (vpn subnet:  
192.168.245.0/24)
Lab 6: port 1196 on the Core pfSense firewall (vpn subnet:  
192.168.244.0/24)
Lab 7: port 1197 on the Core pfSense firewall (vpn subnet:  
192.168.243.0/24)


As I said before - all is working fine - except:  when doing rsync's  
over ssh/scp from the lab machines to the services core, I'm seeing  
a maximum sustained throughput of around 60Mbps.  With gigabit end  
to end - even with the AES encryption overhead of the OpenVPN  
connection and the scp encryption overhead of the file transfer, I  
would have expected higher throughput than this.  The sending  
machines and the receiving server are not showing high CPU load so I  
don't think the encryption is the issue.


Any thoughts or ideas?

Thank you,

Eric





[pfSense Support] unexpected network throughput

2008-03-22 Thread Eric Baenen
Hello, 

I'm very new to pfSense, but I am very impressed. I've installed it in my 
environment and everything is working except I'm getting less network 
throughput than I would have expected and was just wondering if anyone might 
have some insight into why. 

My setup and use of pfSense is admittedly out of the ordinary but it does seem 
to be working fine. 

I have 8 laboratory facilities on a campus interconnected with a flat gigabit 
ethernet standalone backbone (ie. no external access). Each of the laboratories 
is firewalled off from each other (pfSense firewalls) but maintains a permanent 
OpenVPN based VPN connection to a centralized 'core' of services (Zimbra for 
lab-to-lab email/webmail, OpenFire jabber IM server, Apache/TikiWiki 
web/collaboration, BackupPC centralized backup server, centralized file server, 
OSSIM security monitor, etc.). In the near future we will configure individual 
lab to lab VPN connections to facilitate collaboration, resource sharing, etc. 

Seven of the labs connected have the following setup. 

lab machines/servers - lab gigabit switch - pfSense firewall - backbone gigabit 
switch 

The pfSense firewalls are all Dell 2.6GHz GX270's with 512MB RAM, an on-board 
gigabit port, and a second Intel Pro 1000 gigabit NIC. Both ports in each of 
the firewalls appear to be running at 1000base full duplex 

The 8th lab setup is a bit goofy - it's not currently connected and will be the 
subject of a follow up email to this list. 

The VPN connections from each lab to the core are OpenVPN, UDP, shared key, AES 
128bit (for now), LZO compression enabled. 

Each lab network is on a unique IP space - for example: 

Lab 1: 192.168.10.0/24 
Lab 2: 192.168.15.0/24 
Lab 3: 192.168.20.0/24 
Lab 4: 192.168.25.0/24 
Lab 5: 192.168.30.0/24 
Lab 6: 192.168.35.0/24 
Lab 7: 192.168.40.0/24 

Core: 192.168.250.0/24 

I'm not sure if this is the right, best or most efficient way to set up the 
VPN's but based on the instructions on the pfSense site I set up a separate 
OpenVPN tunnel for each lab... 

Lab 1: port 1191 on the Core pfSense firewall (vpn subnet: 192.168.249.0/24) 
Lab 2: port 1192 on the Core pfSense firewall (vpn subnet: 192.168.248.0/24) 
Lab 3: port 1193 on the Core pfSense firewall (vpn subnet: 192.168.247.0/24) 
Lab 4: port 1194 on the Core pfSense firewall (vpn subnet: 192.168.246.0/24) 
Lab 5: port 1195 on the Core pfSense firewall (vpn subnet: 192.168.245.0/24) 
Lab 6: port 1196 on the Core pfSense firewall (vpn subnet: 192.168.244.0/24) 
Lab 7: port 1197 on the Core pfSense firewall (vpn subnet: 192.168.243.0/24) 

As I said before - all is working fine - except: when doing rsync's over 
ssh/scp from the lab machines to the services core, I'm seeing a maximum 
sustained throughput of around 60Mbps. With gigabit end to end - even with the 
AES encryption overhead of the OpenVPN connection and the scp encryption 
overhead of the file transfer, I would have expected higher throughput than 
this. The sending machines and the receiving server are not showing high CPU 
load so I don't think the encryption is the issue. 

Any thoughts or ideas? 

Thank you, 

Eric