[pfSense] Bridging 3 virtual interfaces together?

2014-01-05 Thread Benjamin Swatek
Hi all,

following up on this thread: Bridge LAN ports to act like a switch
http://forum.pfsense.org/index.php?topic=48947.0

I am looking for a way to bridge 3 VLAN interfaces together so they act as one 
inside the pfSense box for the purpose of traffic shaping on the bridge.
Now the 3 interfaces still need to act as single interfaces running 3 different 
DHCP servers on each.

I looked into the above thread, but just bridging the 3 interfaces together 
they loose their IP addresses, which is something that I can’t afford as they 
serve 3 different LANs.

I want to *join* the interfaces together inside pfSense so I can throw all the 
traffic together in one big queue and start shaping according to subnet and 
ports.

Any hints?

Thanks

Ben___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


Re: [pfSense] Bridging 3 virtual interfaces together?

2014-01-05 Thread Adam Thompson

On 14-01-05 09:44 AM, Benjamin Swatek wrote:

Hi all,

following up on this thread: Bridge LAN ports to act like a switch
http://forum.pfsense.org/index.php?topic=48947.0

I am looking for a way to bridge 3 VLAN interfaces together so they 
act as one inside the pfSense box for the purpose of traffic shaping 
on the bridge.
Now the 3 interfaces still need to act as single interfaces running 3 
different DHCP servers on each.


I looked into the above thread, but just bridging the 3 interfaces 
together they loose their IP addresses, which is something that I 
can’t afford as they serve 3 different LANs.


I want to *join* the interfaces together inside pfSense so I can throw 
all the traffic together in one big queue and start shaping according 
to subnet and ports.


Any hints?


That thread makes my head hurt, it's a bunch of people who don't 
understand the difference between Layer 2 and Layer 3 arguing about how 
to make it work.


Here's the only hint I could find:
http://blog.davidvassallo.me/2012/10/23/traffic-shaping-pfsense/

And... the whole *point* of bridging is that you lose the individuality 
of each NIC at Layer 3 (where IP lives).


I think what you might want is to create 3 VLAN interfaces on the trunk 
port, then 1 non-VLAN interface on each of 3 independent NICs, then 
bridge one NIC and one VLAN together... 3 times.  You'll wind up with 3 
bridges.


However, comparing that to the link I provided above doesn't result in 
any obvious solution for you.


Another solution would simply be to route instead of bridging.

As usual, I strongly suggest referring to a primer on the OSI model and 
make sure you fully understand the difference between Layer 2 (ethernet) 
and Layer 3__ (IP), and the corollary, the difference between 
switching/bridging and routing.  You've also got VLANs thrown in there, 
which actually live at layer 2 but have layer 3 implications.


Despite the fact pfSense supports traffic shaping on bridges, I'm not 
certain it'll be possible in your exact scenario without several more 
complicated steps.


--
-Adam Thompson
 athom...@athompso.net

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


[pfSense] strange IPv6 routing problem

2014-01-05 Thread Adam Thompson

I'm having an issue with IPv6 state tracking, I think.

I run a fully dual-stacked environment.
pfSense 2.1-RELEASE acts as the gateway between two subnets (two VLANs, 
but I don't think that makes any difference here).
In IPv4, one subnet (A) is publicly-routable address space, the other 
(B) is RFC1918.

In IPv6, both subnets are publicly-routable address space.
I have a management workstation on subnet A that needs to reach servers 
in subnet B.


I've added two static routes on the router for subnet A, one IPv4, one 
IPv6, pointing to pfSense as the next-hop.
I've disabled automatic outbound NAT, and modified the three 
automatically-generated rules to have Destination NOT subnet A, in other 
words, I don't NAT between subnets A and B, only between B and the 
outside world (via A).  There are no port forwards in place.

On the WAN interface, I have four rules:
1. allow all IPv6 to WAN interface
2. allow all IPv4 to WAN interface
3. allow all IPv6 from A to B
4. allow all IPv4 from A to B

That's it - the simplest possible configuration I could come up with for 
this role.  (Incidentally, the reason I'm using pfSense at all is 
because the two routers for subnet A provide non-stateful HA, which 
makes NAT quite problematic.)


What I see is that when I ssh from A to B using IPv4, everything works 
fine.  The session shows up in the firewall state table as expected, and 
performs as expected.
If I ssh from A to B using IPv6, however, the session connects, I log 
in, and after a short while, the ssh session stalls.  The session does 
NOT show up in the state table, ever, even while it's still working 
properly.
I can restart the SSH session immediately, and it again will work for a 
while, failing after ~50 packets have been exchanged.


I've run simultaneous packet captures on the pfSense WAN and LAN 
interfaces, but they show me nothing of interest.  I looked at 
filter.log, but it's so noisy I didn't get any value out of it yet.


Any ideas or thoughts?  How can my session work in the first place 
without a state table entry, why does it die after ~50-100 packets?  Why 
is only IPv6 affected?  Have I missed something fundamental?


--
-Adam Thompson
 athom...@athompso.net

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


[pfSense] FW: IPSec problem with mobile IOS and Android

2014-01-05 Thread Carlos Vicente
Jim, just one additional info: since I don´t have a public static IP, my ISP
router is using Dyndns.org (paid) service for name resolution.

 

Thanks again.

CV

 

From: Carlos Vicente [mailto:cjpvice...@gmail.com] 
Sent: 5 de janeiro de 2014 18:08
To: 'pfSense support and discussion'
Subject: RE: [pfSense] IPSec problem with mobile IOS and Android

 

Jim, thanks for your rapid answer.

 

The ISP router is a basic one for a cable link. You are right, I’m
attempting to terminate IPSEC on the pfSense box so I configured the ISP
router with the following available options:

-  “Services - Firewall -  Port Forwarding  - Local Host: my
pfSense WAN IP - Protocol Name: IPSec - Internet Protocol Security (Ports
UDP 500, ESP, AH) predefined as a service - Forward to Port: same as
incoming port“.

 

From the doc you referred to (the one I followed), I had to make a change in
the Phase 1 option “NAT Traversal” to “Disabled”, only then I could
establish the Phase 1 Tunnel from the Android tablet (using  3G connection)
with a direct public IP endpoint. I can´t establish any connection if the
same mobile device is using a Wi-Fi/wireless connection (even changing the
“NAT Traversal” to “Force”).

 

I hope this additional info can clarify you of my scenario, so that you can
suggest me a solution. I can post here some logs if you want.

 

Thank you for your help.

CV

 

 

From: list-boun...@lists.pfsense.org [mailto:list-boun...@lists.pfsense.org]
On Behalf Of Jim Thompson
Sent: 5 de janeiro de 2014 02:25
To: pfSense support and discussion
Subject: Re: [pfSense] IPSec problem with mobile IOS and Android

 

you lost me at “port forwarding”.

 

Making NAT work for IPSEC (passthrough) can be … quite challenging.

 

 

Hopefully you’re attempting to terminate IPSEC on the pfSense box, and the
ISP router is configured to:

· IP Protocol ID 50:  For both inbound and outbound filters. Should
be set to allow Encapsulating Security Protocol (ESP) traffic to be
forwarded.

· IP Protocol ID 51:  For both inbound and outbound filters. Should
be set to allow Authentication Header (AH) traffic to be forwarded.

· UDP Port 500:  For both inbound and outbound filters. Should be
set to allow ISAKMP traffic to be forwarded.

 

Note that ‘forwarding’ here is packet forwarding, not port forwarding.   If
so, I’ve simply misunderstood you.  If not, you’re not going to make it work
without a TON of work on NAT-traversal.

 

You say you looked at: https://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0
(I think).   Commercial support is available if you need it.

 

Jim

 

On Jan 4, 2014, at 5:03 PM, Carlos Vicente cjpvice...@gmail.com wrote:

 

Hi all,

 

I have a problem with an IPSec VPN from mobile clients (IOS and Android). I
can establish the tunnel but can’t ping, RDP or SSH the pfSense or any
client behind it (which is working with OpenVPN). I see the “passed” logs on
the firewall tab but can’t access the systems.

 

My pfSense WAN is on the same subnet as the LAN of the ISP router, which has
port forwarding of ESP, AH and IKE to the pfSense WAN network adapter. All
the rules are correct and I they appear correctly on logs.

 

My PfSense version is 2.0.3 upgraded from 1.2.3. I have tried all kind of
configs from the doc “
https://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0 Mobile IPsec on
2.0”, but, as I said, can establish the connection but can´t access any
device on LAN subnet.

 

I use this excellent appliance for many years, so I must have IPSec VPN
working on mobile clients the same way I have them working with OpenVPN.

 

I’m stuck here, so any help would be very appreciated.

 

Thanks.

CV

___
List mailing list
 mailto:List@lists.pfsense.org List@lists.pfsense.org
 http://lists.pfsense.org/mailman/listinfo/list
http://lists.pfsense.org/mailman/listinfo/list

 

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


Re: [pfSense] IPSec problem with mobile IOS and Android

2014-01-05 Thread Jim Spaloss
Carlos,

You may want to try enabling the DMZ option (if it's available) on the
ISP's router and directing all traffic to the wan address of the PFSense
box.
I've run into the same issue with Comcast business class routers. They're
very light on features and I've seen some firmware versions that attempt to
implement basic VPN functionality which seems to override NAT settings. The
DMZ option seems to work better.
Of course, getting a static IP would make your life easier, assuming that
it is available...
On Jan 5, 2014 1:08 PM, Carlos Vicente cjpvice...@gmail.com wrote:

 Jim, thanks for your rapid answer.



 The ISP router is a basic one for a cable link. You are right, I’m attempting
 to terminate IPSEC on the pfSense box so I configured the ISP router with
 the following available options:

 -  “Services - Firewall -  Port Forwarding  - Local Host: my
 pfSense WAN IP - Protocol Name: IPSec - Internet Protocol Security (Ports
 UDP 500, ESP, AH) *predefined as a service* - Forward to Port: same as
 incoming port“.



 From the doc you referred to (the one I followed), I had to make a change
 in the Phase 1 option “NAT Traversal” to “Disabled”, only then I could
 establish the Phase 1 Tunnel from the Android tablet (using  3G connection)
 with a direct public IP endpoint. I can´t establish any connection if the
 same mobile device is using a Wi-Fi/wireless connection (even changing the 
 “NAT
 Traversal” to “Force”).



 I hope this additional info can clarify you of my scenario, so that you
 can suggest me a solution. I can post here some logs if you want.



 Thank you for your help.

 CV





 *From:* list-boun...@lists.pfsense.org [mailto:
 list-boun...@lists.pfsense.org] *On Behalf Of *Jim Thompson
 *Sent:* 5 de janeiro de 2014 02:25
 *To:* pfSense support and discussion
 *Subject:* Re: [pfSense] IPSec problem with mobile IOS and Android



 you lost me at “port forwarding”.



 Making NAT work for IPSEC (passthrough) can be … quite challenging.





 Hopefully you’re attempting to terminate IPSEC on the pfSense box, and the
 ISP router is configured to:

 · IP Protocol ID 50:  For both inbound and outbound filters.
 Should be set to allow Encapsulating Security Protocol (ESP) traffic to be
 forwarded.

 · IP Protocol ID 51:  For both inbound and outbound filters.
 Should be set to allow Authentication Header (AH) traffic to be forwarded.

 · UDP Port 500:  For both inbound and outbound filters. Should be
 set to allow ISAKMP traffic to be forwarded.



 Note that ‘forwarding’ here is packet forwarding, not port forwarding.
 If so, I’ve simply misunderstood you.  If not, you’re not going to make it
 work without a TON of work on NAT-traversal.



 You say you looked at:
 https://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0 (I think).
 Commercial support is available if you need it.



 Jim



 On Jan 4, 2014, at 5:03 PM, Carlos Vicente cjpvice...@gmail.com wrote:



 Hi all,



 I have a problem with an IPSec VPN from mobile clients (IOS and Android).
 I can establish the tunnel but can’t ping, RDP or SSH the pfSense or any
 client behind it (which is working with OpenVPN). I see the “passed” logs
 on the firewall tab but can’t access the systems.



 My pfSense WAN is on the same subnet as the LAN of the ISP router, which
 has port forwarding of ESP, AH and IKE to the pfSense WAN network adapter.
 All the rules are correct and I they appear correctly on logs.



 My PfSense version is 2.0.3 upgraded from 1.2.3. I have tried all kind of
 configs from the doc “Mobile IPsec on 
 2.0https://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0”,
 but, as I said, can establish the connection but can´t access any device on
 LAN subnet.



 I use this excellent appliance for many years, so I must have IPSec VPN
 working on mobile clients the same way I have them working with OpenVPN.



 I’m stuck here, so any help would be very appreciated.



 Thanks.

 CV

 ___
 List mailing list
 List@lists.pfsense.org
 http://lists.pfsense.org/mailman/listinfo/list



 ___
 List mailing list
 List@lists.pfsense.org
 http://lists.pfsense.org/mailman/listinfo/list


___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


Re: [pfSense] strange IPv6 routing problem

2014-01-05 Thread Nicolas Bélan
Hello :)

Sure it is strange, can you launch ssh server in debug mode (non
detaching daemon) and check /var/log/message or secure in B ?
Can you also provide a packet capture with tcp flags ?
It may be different causes ...

maybe the cause is located on B, or on pfsense ...not sure ...

Best regards
Nicolas
Le 05/01/2014 17:28, Adam Thompson a écrit :
 I'm having an issue with IPv6 state tracking, I think.

 I run a fully dual-stacked environment.
 pfSense 2.1-RELEASE acts as the gateway between two subnets (two
 VLANs, but I don't think that makes any difference here).
 In IPv4, one subnet (A) is publicly-routable address space, the
 other (B) is RFC1918.
 In IPv6, both subnets are publicly-routable address space.
 I have a management workstation on subnet A that needs to reach
 servers in subnet B.

 I've added two static routes on the router for subnet A, one IPv4, one
 IPv6, pointing to pfSense as the next-hop.
 I've disabled automatic outbound NAT, and modified the three
 automatically-generated rules to have Destination NOT subnet A, in
 other words, I don't NAT between subnets A and B, only between B and
 the outside world (via A).  There are no port forwards in place.
 On the WAN interface, I have four rules:
 1. allow all IPv6 to WAN interface
 2. allow all IPv4 to WAN interface
 3. allow all IPv6 from A to B
 4. allow all IPv4 from A to B

 That's it - the simplest possible configuration I could come up with
 for this role.  (Incidentally, the reason I'm using pfSense at all is
 because the two routers for subnet A provide non-stateful HA, which
 makes NAT quite problematic.)

 What I see is that when I ssh from A to B using IPv4, everything works
 fine.  The session shows up in the firewall state table as expected,
 and performs as expected.
 If I ssh from A to B using IPv6, however, the session connects, I log
 in, and after a short while, the ssh session stalls.  The session does
 NOT show up in the state table, ever, even while it's still working
 properly.
 I can restart the SSH session immediately, and it again will work for
 a while, failing after ~50 packets have been exchanged.

 I've run simultaneous packet captures on the pfSense WAN and LAN
 interfaces, but they show me nothing of interest.  I looked at
 filter.log, but it's so noisy I didn't get any value out of it yet.

 Any ideas or thoughts?  How can my session work in the first place
 without a state table entry, why does it die after ~50-100 packets? 
 Why is only IPv6 affected?  Have I missed something fundamental?


___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


Re: [pfSense] Bridging 3 virtual interfaces together?

2014-01-05 Thread Benjamin Swatek

On 5, Jan2014, at 15:59 , Adam Thompson athom...@athompso.net wrote:

 On 14-01-05 12:49 PM, Benjamin Swatek wrote:
 Thanks for your help Adam, I got to admit that I definitely do NOT fully 
 understand OSI ;-)
 
 Unfortunately, most people working with firewalls do not.  It's like an auto 
 mechanic working on your transmission without understanding how gears work, 
 IMHO...
 
Wouldn’t call myself an auto mechanic neither ;-) - Yeah, I only have a little 
idea of what I’m doing here.
 
 The reason for the VLANs was to get the 3 LANs onto one NIC in the first 
 place, hoping that it would be easier to “get them together” for shaping 
 then having them come in on the pfSense box on 3 physical NICs.
 
 Looking at your answer this might be the wrong approach.
 
 If you have any suggestions as on how I can take the traffic from 3 LANs and 
 pipe it through a traffic shaper where I can prioritise traffic from a 
 certain LAN over another and prioritise certain traffic over other within 
 each LANs traffic, I’d be very great full to hear…
 
 1. Recall that priority/QoS is irrelevant until/unless the link is congested. 
  So unless you plan to push ~ 1.0 Gbps of traffic, stop now and don't waste 
 your time.  Unless this is just a learning experience anyway, in which case 
 go right ahead.
 

I’m only looking to push 8Mbps through two 3Mbps and one 2 Mbps ADSL lines 
(MultiWAN) for each of which I pay more than the national minimum wage - this 
is Bolivia - trying to satisfy my business’s needs to answer to emails asap as 
well as my clients expectations for a fast WiFi - that is people who don’t have 
a clue how expensive 1 Mbps is compared to the 1st world.
So yes, my links are constantly congested ;-)

 2. Although FreeBSD's if_bridge (we are using this, not ng_bridge(4), right, 
 guys??) supports bridging tagged packets, I don't see anywhere in the docs a 
 way to set and strip VLAN tags the way a real switch would.  Perhaps you'll 
 be better off just buying a cheap managed switch off eBay to do this job, for 
 example http://r.ebay.com/CkaSX0 isn't what I'd choose for enterprise use but 
 will be more than adequate for home use.  If you don't like used equipment, 
 look at the NetGear GS(105|108|116)* line which are small, cheap and fanless, 
 and will do almost everything you want to do.  Minus the QoS, I think... 
 although they have slightly more expensive (but still small and fanless, I 
 think) models that can do QoS.  Most vendors have a small, quiet, 
 VLAN-capable switch like this, but I think Netgear's are the cheapest (and 
 have lifetime warranty).
 
I have a TP-Link 8 port switch ( http://tinyurl.com/m2rbcdt ) that connects the 
3 LANs and the 3 WANs to the pfSense Box. 
But I’m not sure anymore what help it is.
I had the LANs coming in on their own physical NICs, but couldn’t get them 
together for QoS neither.
I can get them all in their own queue for shaping, but that way I could only 
limit each LAN individually not taking into account what the other one needs.

 3. You could probably get some low-profile Cat5e cable and run multiple runs 
 in the wiring space you currently have a single cable run.  This requires 
 skill and tools, however.
Cables are there, if that would help at all I can run more.

 
 4. Do all of this with routing instead of bridging.  IIRC, you mentioned that 
 due to physical limitations, the pfSense device acting as a switch was 
 relatively underpowered; this will affect layer 2 (bridging) performance as 
 well, so whether you route or bridge, you still won't be able to push a 
 gigabit of traffic, and QoS will likely make the situation worse, not better.
 
There are no real physical limitations around the pfSense Box (Intel Pentium D 
3 GHz - 2 GB RAM), all LANs come all the way down to the box, the modems for 
the 3 WAN connections sit right next to it too.

The limit is the available bandwidth here in Bolivia, 3Mbps ADSL costs around $ 
200 (US) per month which equals to the local minimum wage. We have 3 of those 
connections, serving our Office’s LAN, Client PC LAN and Clients WiFi in my 
Backpacker Hostel with sometimes up to 120 devices connected to the WiFi…

So if you have any further suggestion on where to look (RTFM) how to do some 
routing so I can shape the traffic between the LANs, I am happy to read any 
manual you could suggest.

Thanks

Ben

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


Re: [pfSense] Bridging 3 virtual interfaces together?

2014-01-05 Thread Adam Thompson

On 14-01-05 08:56 PM, Benjamin Swatek wrote:
I’m only looking to push 8Mbps through two 3Mbps and one 2 Mbps ADSL 
lines (MultiWAN) for each of which I pay more than the national 
minimum wage - this is Bolivia - trying to satisfy my business’s needs 
to answer to emails asap as well as my clients expectations for a fast 
WiFi - that is people who don’t have a clue how expensive 1 Mbps is 
compared to the 1st world.

So yes, my links are constantly congested ;-)


Oops, I've mixed you up in my mind with someone else who recently asked 
for assistance with VLANs and trunking, but they wanted to use a pfSense 
box *as* a switch.

I've steered you the wrong way altogether!

I have a TP-Link 8 port switch ( http://tinyurl.com/m2rbcdt ) that 
connects the 3 LANs and the 3 WANs to the pfSense Box.

But I’m not sure anymore what help it is.
I had the LANs coming in on their own physical NICs, but couldn’t get 
them together for QoS neither.
I can get them all in their own queue for shaping, but that way I 
could only limit each LAN individually not taking into account what 
the other one needs.


You've got everything you need.

The only place you can usefully control QoS in your environment is on 
the *UP*link to your ADSL provider.  If you have NICs dedicated to each 
subnet, then you're already at 1Gbps dedicated to each subnet.  Not 
really, because pfSense on that hardware can't do 1Gbps, but at least 
ethernet isn't the bottleneck.


By controlling upstream bandwidth, you can have *some* effect on 
downstream bandwidth.  By ensuring that no single upstream link is 100% 
congested, you will almost certainly improve response time and latency.


There will be absolutely no benefit to putting a traffic-shaping policy 
on inbound traffic; I can explain the logic behind this statement if 
it's not obvious, but in short: the data has already arrived at the DSL 
modem (and thereby filled up the pipe) long before pfSense can touch it; 
by the time pfSense sees the packet, it's far too late to do any traffic 
shaping.  If you could put a matching pfSense box at the ISP's location 
(hooked up to a 10- or 100-Mbit port), you could then usefully apply QoS 
in both directions.  But, good luck with that, most ISPs (speaking as a 
former ISP operator, here) won't understand or care, or if they do 
they'll charge you an arm and a leg.


I believe what you need is a standard multi-WAN setup.  No VLANs or 
trunking are needed at all in your situation.  You will need to apply a 
traffic shaping policy on all three WAN connections; you can apply the 
identical policy on all, or different policies on each. If you're using 
pfSense's multi-WAN feature with equal weights, I recommend placing the 
same traffic policies on all three lines.


However, bundling the three DSL connections together this way won't 
produce the results you expect; pfSense doesn't magically bond uplinks 
and downlinks together - no standard router or firewall really can do a 
good job of that.  pfSense does a decent job of load-balancing, but the 
end results are imperfect and do not magically reflect a 3x increase in 
usable bandwidth.


Make sure you read https://doc.pfsense.org/index.php/Multi-WAN_2.0 ; you 
might want to buy the pfSense book, it's included in the $99 Gold 
subscription from Electric Sheep Fencing (see 
https://portal.pfsense.org/subscribe-for-access.php).


You might want to have a look at Mushroom's Truffle router.  Yes, I'm 
serious, that's the real name of the product.  It might be useful to 
you, or it might not.  Latency from Bolivia might suck if you use their 
cloud service on the far end; you might still have to find somewhere to 
host the server side to get the most out of the bonding mode they offer.


Good luck, feel free to ask for clarification here if needed.

--
-Adam Thompson
 athom...@athompso.net

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list


Re: [pfSense] Bridging 3 virtual interfaces together?

2014-01-05 Thread Benjamin Swatek

On 5, Jan2014, at 23:48 , Adam Thompson athom...@athompso.net wrote:

 I've steered you the wrong way altogether!

No Problem
 
 I have a TP-Link 8 port switch ( http://tinyurl.com/m2rbcdt ) that connects 
 the 3 LANs and the 3 WANs to the pfSense Box.
 But I’m not sure anymore what help it is.
 I had the LANs coming in on their own physical NICs, but couldn’t get them 
 together for QoS neither.
 I can get them all in their own queue for shaping, but that way I could only 
 limit each LAN individually not taking into account what the other one needs.
 
 You've got everything you need.
 
 The only place you can usefully control QoS in your environment is on the 
 *UP*link to your ADSL provider.  If you have NICs dedicated to each subnet, 
 then you're already at 1Gbps dedicated to each subnet.  Not really, because 
 pfSense on that hardware can't do 1Gbps, but at least ethernet isn't the 
 bottleneck.
 
 By controlling upstream bandwidth, you can have *some* effect on downstream 
 bandwidth.  By ensuring that no single upstream link is 100% congested, you 
 will almost certainly improve response time and latency.
 
I thought that is some how what the pfSense Shaper does, I imagined that by 
keeping responses of certain connections back, it would also somehow limit the 
downstream or some similar black magic ;-)

 There will be absolutely no benefit to putting a traffic-shaping policy on 
 inbound traffic; I can explain the logic behind this statement if it's not 
 obvious, but in short: the data has already arrived at the DSL modem (and 
 thereby filled up the pipe) long before pfSense can touch it.

No black magic at all so? 
Not even to limit p2p traffic and prefer pure http/https ?

Or give one LAN more bandwidth when needed while more to the other LAN if the 
first one doesn’t need it?

 I believe what you need is a standard multi-WAN setup.  No VLANs or trunking 
 are needed at all in your situation.  You will need to apply a traffic 
 shaping policy on all three WAN connections; you can apply the identical 
 policy on all, or different policies on each. If you're using pfSense's 
 multi-WAN feature with equal weights, I recommend placing the same traffic 
 policies on all three lines.
 
Up and running

 However, bundling the three DSL connections together this way won't produce 
 the results you expect; pfSense doesn't magically bond uplinks and downlinks 
 together - no standard router or firewall really can do a good job of that.  
 pfSense does a decent job of load-balancing, but the end results are 
 imperfect and do not magically reflect a 3x increase in usable bandwidth.

You’d be surprised how good of a Job it does. When the connections are good, 
less other Bolivians surfing the web, and each DSL line nearly reaches it’s 
(contracted) limit, the Client WiFi nearly suck`s down the sum of the 3 DSL 
bandwidth, that is according to pfSense’s traffic graphs :-)

 
 You might want to have a look at Mushroom's Truffle router.  Yes, I'm 
 serious, that's the real name of the product.  It might be useful to you, or 
 it might not.  Latency from Bolivia might suck if you use their cloud service 
 on the far end; you might still have to find somewhere to host the server 
 side to get the most out of the bonding mode they offer.
 
I’ll look into this.

Thanks

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list