[pfSense] Migrate RRD data between 32-bit and 64-bit systems.
Since a bunch of people have asked about this, here's a quick HOWTO. First locate your current DB files. Since my box isn't running any more, I can't remember where they live - probably /var/db/rrd ... but if it's a full install, it could also be in /conf/db/rrd if I remember correctly. I didn't actually do that ... I just made a backup of my configuration including the RRD data (in the pfSense GUI). The old install was a full HDD install). When I restored it on the new install (a nano install only as I've been having problems with drive reliability), it put a file rrd.tgz in /conf ... that one contained all the files. With the .rrd files in hand, you first have to get them exported to XML. On a 32-bit system (can be a plain Linux box), use rrdtool to dump the DB to an xml file: rrdtool dump rrdfile xmlfile With these XML files, you can create new platform RRD files. On a 64-bit system (again, can be a plain Linux box), use rrdtool to create a new DB file: rrdtool restore xmlfile rrdfile The resulting .rrd files can simply be copied into the var/db/rrd directory - overwriting the files already there. It gets a little trickier if you need to merge RRD files For example if you install the new version pfSense for a few days, regret and revert back to the old version. Now your RRD graphs will have a big fat hole in them ... unless you merge the 2 sets of graphs. It used to be simple enough to do (there's a python tool called merge-rrd), but when I tried it earlier, I found out that the tool no longer works due to a small change in the exported XML. In any case, I solved it ... look here if you need it. http://forums.cacti.net/viewtopic.php?f=21t=38560 Regards, -Jeppe ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense 2.0 - Filtering traffic on OpenVPN
On Thu, Oct 13, 2011 at 16:03, Tim Nelson tnel...@rockbochs.com wrote: I would expect it to work this way also. However, I've removed the OPT interfaces corresponding to the OpenVPN servers. Next, I've added one rule to 'Allow all traffic, any protocol, any source, any destination, etc' the OpenVPN tab in the firewall rules page. This should allow all traffic from all clients. However, even after saving, then clearing the state table, I'm not able to pass traffic over any of the OpenVPN links. I should mention, this system was upgraded from 1.2.1 to 2.0-RELEASE. Also, I did *not* uninstall any packages prior to the upgrade (read the upgrade notes afterwards... :/ ). Does this have any relevance? Should I reinstall this system from scratch, then recreate each VPN server/interface? Maybe just delete all the VPN servers, and start fresh? which direction are you trying the connectivity? the rules on the openvpn tab are for connections coming from the remote system to the pfSense box. If you want to connect out from local boxes to the remote system over the vpn then you need appropriate rules on the relavent interface (such as lan) to allow the traffic. -- Regards, The Honeymonster aka Daniel Llewellyn ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense 2.0 - Filtering traffic on OpenVPN
- Original Message - On Thu, Oct 13, 2011 at 16:03, Tim Nelson tnel...@rockbochs.com wrote: I would expect it to work this way also. However, I've removed the OPT interfaces corresponding to the OpenVPN servers. Next, I've added one rule to 'Allow all traffic, any protocol, any source, any destination, etc' the OpenVPN tab in the firewall rules page. This should allow all traffic from all clients. However, even after saving, then clearing the state table, I'm not able to pass traffic over any of the OpenVPN links. I should mention, this system was upgraded from 1.2.1 to 2.0-RELEASE. Also, I did *not* uninstall any packages prior to the upgrade (read the upgrade notes afterwards... :/ ). Does this have any relevance? Should I reinstall this system from scratch, then recreate each VPN server/interface? Maybe just delete all the VPN servers, and start fresh? which direction are you trying the connectivity? the rules on the openvpn tab are for connections coming from the remote system to the pfSense box. If you want to connect out from local boxes to the remote system over the vpn then you need appropriate rules on the relavent interface (such as lan) to allow the traffic. I'm attempting to connect from a client to a device on the LAN which means the traffic should be hitting the filter rule on the OpenVPN tab, which allows all traffic. --Tim ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense 2.0 - Filtering traffic on OpenVPN
Most of the times I have had trouble with the routing and not with the firewall rules. Check if the client has the correct gateway set for the LAN subnet and check if the push route is added correctly. A traceroute from the client can help you see if the packets are being send through the VPN tunnel. If it is actually the firewall blocking, you should be able to see the block in the firewall log. Vassilis ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
[pfSense] some pptp questions
Hello, I have a few questions about configuring pptp in pfsense 2.0 RELEASE. Hoping someone can clue me in. What determines the size of the pptp address pool? I got the impression from one of the how-tos that it's hard coded to a /28 subnet. If that's the case, what's the purpose of the number of users parameter in the pptp setup page (which covers way more than /28 addresses)? If I pull pptp addresses out of the LAN address space does pfsense isolate those two spaces? Or rather, how well are the two spaces isolated? Is there some sort of best practice that I should follow? Fiinally, pfsense allows me to map a given user to a particular address. Is this relationship two-way exclusive? My intent is to enable admin access via pptp in such a way that non-admin users can't wander into the admin's lane. TIA, eric PS: Has the update server been down for the last couple of days? ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
[pfSense] Traffic shaping query
Hi all. I am in the process of replacing a Fortinet firewall with a nice shiny pfSense virtual appliance and am trying to plan our traffic shaping/qos but I'm having trouble getting my head around it. We currently have 11 LAN segments and a single WAN. We are not really interested in shaping/prioritising the inter-LAN traffic, just inbound and outbound WAN traffic. My idea so far is to simply use limiters for inbound traffic (as we cannot influence the order that packets arrive from the ISP so HFSC does not seem any better for this purpose, just more complicated) and use HFSC to prioritize and shape outbound traffic. This configuration means I only need to create one set of limiters for inbound traffic (as opposed to a set of queues for each interface with HFSC) and one set of HFSC queues on the WAN interface for outbound traffic. We have a 10Mb/10Mb connection which is shared between users internet access, web/dns/mail hosting and guest internet access, so I really want to get my QoS right to make the most of this connection. The configuration I am thinking of implementing is: Inbound traffic (Downloads) 3Mbit Limiter (For all data requested by the outside world, i.e. served by us) Priority traffic (e.g. VoIP traffic DNS requests) highest weighting Standard traffic (e.g. FTP, HTTP requests) medium weighting Low Priority traffic (e.g. SMTP, POP3 IMAP connections) lowest weighting 7Mbit Limiter (For all data served by external systems, i.e. requested by us) Priority traffic (e.g. VoIP traffic, DNS requests) highest weighting Standard traffic (e.g. VPN, Remote Desktop, FTP, HTTP) medium weighting Low Priority traffic (e.g. SMTP, POP3, IMAP etc.) low weighting Penalty traffic (everything else not classified above) lowest weighting Outbound traffic (Uploads) 9700Kbit Root Class (97% of Max WAN upload) Ack Traffic - Priority 7, Bandwidth 15%, Qlimit 500, Realtime 10% DNS Traffic - Priority 6, Bandwidth 5%, Realtime 5% Served Traffic (e.g. traffic sent by our servers) - Priority 6, Bandwidth 50%, Upperlimit 80%, Realtime 50% VoIP - Priority 6, Bandwidth 10%, Upperlimit (35% 30ms 10%), Realtime 10% RDP/VNC - Priority 5, Bandwidth 20%, Upperlimit (50%, 200, 10%), Realtime 15% HTTP/HTTPS/FTP - Priority 4, Bandwidth 50%, Realtime (75%, 1, 40%) Mail - Priority 3, Bandwidth 20%, Realtime 10% Client Traffic (e.g. Client uploads, VoIP traffic, VPN traffic etc.) - Priority 5, Bandwidth 20%, Upperlimit 50%, Realtime 25% VoIP - Priority 6, Bandwidth 10%, Upperlimit (35% 30ms 10%), Realtime 20% RDP/VNC - Priority 5, Bandwidth 30%, Upperlimit (50%, 200, 10%), Realtime 15% HTTP/HTTPS/FTP - Priority 4, Bandwidth 50%, Realtime (75%, 1, 40%) Mail - Priority 3, Bandwidth 10%, Realtime 10% Unclassified Traffic (Anything that wasn't caught by the above rules) - Priority 3, Bandwidth 10%, Upperlimit 30%, Realtime 10% Does anyone see any problems with this configuration? Feel free to shoot me down in flames if this won't work for any reason, I want to get this right. Cheers, Daniel ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] pfSense 2.0 - Filtering traffic on OpenVPN
- Original Message - In 2.0 each interface is renamed in a unique way so you do not need dev tun or any similar entries in the options. You can assign the interfaces if you want (set an IP type of 'none' on them) and filter individually if you want, too. I run with two of mine assigned and 3+ more unassigned and have no issues. After working on this off and on, I finally found pfSense to handle the rules properly. The issue it seems is that once the OPT interface is created for the OpenVPN service instance, the OpenVPN server needs to be restarted for the OPT to pick up the interface IP address. It will then apply the rules appropriately. My clue was seeing the OPT interfaces on the system dashboard as up (green), but no IP assigned. Thanks Jim and others for your helpful suggestions. --Tim ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Traffic shaping query
-Original Message- From: list-boun...@lists.pfsense.org [mailto:list- boun...@lists.pfsense.org] On Behalf Of Daniel Davis Sent: Thursday, October 13, 2011 19:14 To: 'list@lists.pfsense.org' Subject: [pfSense] Traffic shaping query Hi all. I am in the process of replacing a Fortinet firewall with a nice shiny pfSense virtual appliance and am trying to plan our traffic shaping/qos but I'm having trouble getting my head around it. We currently have 11 LAN segments and a single WAN. We are not really interested in shaping/prioritising the inter-LAN traffic, just inbound and outbound WAN traffic. My idea so far is to simply use limiters for inbound traffic (as we cannot influence the order that packets arrive from the ISP so HFSC does not seem any better for this purpose, just more complicated) and use HFSC to prioritize and shape outbound traffic. This configuration means I only need to create one set of limiters for inbound traffic (as opposed to a set of queues for each interface with HFSC) and one set of HFSC queues on the WAN interface for outbound traffic. We have a 10Mb/10Mb connection which is shared between users internet access, web/dns/mail hosting and guest internet access, so I really want to get my QoS right to make the most of this connection. The configuration I am thinking of implementing is: [...] Does anyone see any problems with this configuration? Feel free to shoot me down in flames if this won't work for any reason, I want to get this right. While I don't claim to be a QoS expert, never mind a pfSense QoS expert, I already see one very common (nearly ubiquitous) mistake: limiters on inbound traffic are completely useless. All you're doing is (potentially) dropping packets on the floor. You cannot directly influence what your upstream is sending you, it's already too late by the time it gets to you. You may as well just take it all in the order it came. Your upstream isn't going to send more data to you than the line can handle; that's impossible, just like you can't *send* more data upstream than the line can handle. Remember: QoS only affects packets the QoS-applying device *SENDS*. If you want to influence received packets, you need to fiddle with the TCP window sizes, selectively drop packets, etc. on the way OUT, not on the way in. As a rule of thumb, if you want to reserve a portion of the bandwidth for VoIP, you're going to be stuck with one of three options: 1. convince your upstream provider to priorize VoIP traffic 2. enforce draconian limits on TCP bandwidth usage, shaping traffic such that you only use ~50% of your pipe 3. use a separate link for VoIP, and dedicate it exclusively to real-time traffic. Of course, you can priorize VoIP packets leaving your network, which is good practice, and that will make *you* sound better to the person on the other end of the call. If your upstream provider supports RSVP (fat chance!) you can influence upstream QoS that way, but you still can't affect it by applying policies to received data. There is one exception to this: if the pipe to the internet is *faster* than any of your LAN segments, then applying inbound policies does make sense, because you have to make some decisions about which packets to drop. I haven't yet seen an installation where this is the case, however. Think of IP packets as physical things (something that flows through a funnel, like water or sand) and imagine the router on each end of the pipe as funnels with the narrow ends pointing at each other. QoS only affects congested networks (where there's more data to send than there is available bandwidth). It seems useful even on low-utilization links because there's a lot more instantaneous congestion than you'd expect, but each congestion event only lasts for a millisecond; on an internet-facing router, QoS mostly affects what order two packets go out in during the same millisecond. The QoS policies you apply dictate the precise shape of your funnel; the QoS policies your ISP applies dictates the precise shape of the funnel on their end. The other aspect to QoS is TCP shaping; strictly speaking, that's traffic shaping, not QoS. I believe pfSense can do some traffic shaping as well as QoS. And some drastic QoS-ish measures (selectively dropping packets) amount to traffic shaping in their own right, although that's usually like using a sledgehammer to kill a fly. To perform TCP traffic shaping with QoS-only primitives, you need to simulate TCP ACK Starvation; whereby the limiting factor on a TCP flow is how fast the ACKs can be sent back to the transmitting side. Simple ordering CAN affect traffic flows to a small degree, because if sender A gets its ACK before sender B does, there's a likelihood that sender A will transmit the next packet before sender B does, which means there's a likelihood that sender A's packets will reach your router first, which means better (or
