Reflection
-
I'm sorry, but I can't verify your problems atm as I don't have a testsetup for these :-
I neither can't say these are real bugs nor that something is missconfigured. I suggest trying the soon available beta3. Please reference all your unanswered problems here if they still exist after beta3. -
I looked up your post.. this the problem your having with squid?
My default Gateway is a pfsense at 192.168.1.2 with a PPPOE connection and I have a second pfsense with an other pppoe connection and a working squid at 192.168.1.4.
the Firewall rules are lazy for testing.
When I change my default gateway to 192.168.1.4 the squid works fine in transparent mode with a nat rule:
LAN TCP 80 192.168.1.4 (ext.: any) 3128But when i change my gatewy to 192.168.1.2 and add the same nat rule:
LAN TCP 80 192.168.1.4 (ext.: any) 3128
to this box, I simply get no HTTP answers.It wont work because when the squid box on the lan tries to make a http request, its just like any other computer on the lan trying to make a http requests It is redirected to the squid host. so the request from your browser is redirected to lan host 192.168.1.4 and in turn when squid on that box tries to satisfy the request, the firewall redirects it again back to itself, sending the request in a loop. The only way to get around this is if we add an option to specify the addresses or networks to redirect or not to redirect.
Also Not sure if the 1Kb/s problem is related but try beta3. I'll see what can happen for redirect rules. -
It wont work because when the squid box on the lan tries to make a http request, its just like any other computer on the lan trying to make a http requests It is redirected to the squid host. so the request from your browser is redirected to lan host 192.168.1.4 and in turn when squid on that box tries to satisfy the request, the firewall redirects it again back to itself, sending the request in a loop. The only way to get around this is if we add an option to specify the addresses or networks to redirect or not to redirect.
Actually there should be some magic "behind the scenes" excluding the host the traffic is redirected to from the redirection loop. Geekgod worked something out and last time I checked that it was working. I just don't have a testsetup for this condition atm.
-
I looked up your post.. this the problem your having with squid?
My default Gateway is a pfsense at 192.168.1.2 with a PPPOE connection and I have a second pfsense with an other pppoe connection and a working squid at 192.168.1.4.
the Firewall rules are lazy for testing.
When I change my default gateway to 192.168.1.4 the squid works fine in transparent mode with a nat rule:
LAN TCP 80 192.168.1.4 (ext.: any) 3128But when i change my gatewy to 192.168.1.2 and add the same nat rule:
LAN TCP 80 192.168.1.4 (ext.: any) 3128
to this box, I simply get no HTTP answers.It wont work because when the squid box on the lan tries to make a http request, its just like any other computer on the lan trying to make a http requests It is redirected to the squid host. so the request from your browser is redirected to lan host 192.168.1.4 and in turn when squid on that box tries to satisfy the request, the firewall redirects it again back to itself, sending the request in a loop. The only way to get around this is if we add an option to specify the addresses or networks to redirect or not to redirect.
Also Not sure if the 1Kb/s problem is related but try beta3. I'll see what can happen for redirect rules.I am very glad for this replys. Thank you.
I dont realy understand what you mean with the loop, because the second pfsense box with the squid has s second PPPOE Wan connection.
Isn't it like that:
The Client sends a http request to the default gateway(192.168.1.2) with a randomized source port and port 80 as the destination. This box redirect it (either with the NAT rule directly to 192.168.1.4 port 3128, or the outgoing loadbalancing pool and a firewall rule to 192.168.1.4 and then the redirect to port 3128 on the second box) to the second pfsense box, and create a state entry for this connection. The squid on this box reads out the http header for the original IP adress and sends the request thru his own PPPOE connection. The reply comes and the squid answers to the gateway on 192.168.1.2. This should keep track the connection and forwards it to the source port of the original client.I have not tried beta3 for now (I will do this shortly), but is this not the way it works?
Hoping for replays.
A learning techatdd… -
Ok, i retested it now updated the to boxes to beta 3, but no sucess :-(
Should I report this as a bug (at least the not working internal NAT Rule)? -
Ok, i retested it now updated the to boxes to beta 3, but no sucess :-(
Should I report this as a bug (at least the not working internal NAT Rule)?Please post something about this, I can also do some other tests. I have 3 PPPOE conections with 3 pppoe boxes for testing.
-
Ok, i retested it now updated the to boxes to beta 3, but no sucess :-(
Should I report this as a bug (at least the not working internal NAT Rule)?Please post something about this, I can also do some other tests. I have 3 PPPOE conections with 3 pppoe boxes for testing.
check the cvstrac timeline, I believe this has been fixed.
-
check the cvstrac timeline, I believe this has been fixed.
I have checked this, but cant found anything.
I tested it with Beta3 on both boxes (I think there are no newer snapshots) and the problem still exists. -
check the cvstrac timeline, I believe this has been fixed.
I have checked this, but cant found anything.
I tested it with Beta3 on both boxes (I think there are no newer snapshots) and the problem still exists.Maybe we don't completely understand your bug, but this commit:
http://cvstrac.pfsense.com/chngview?cn=11516
fixed what I believe is what you are reporting. And it was in b3.–Bill
-
Maybe we don't completely understand your bug, but this commit:
http://cvstrac.pfsense.com/chngview?cn=11516
fixed what I believe is what you are reporting. And it was in b3.–Bill
There are too different bugs:
(Configuration: 192.168.1.2 pfsense Beta3 with a PPPOE Wan Connection as the default gateway and 192.168.1.4 pfsense running squid with a second PPPOE Wan connection.)
First. When I configure a Nat rule on the 192.168.1.2 for redirecting http traffic to 192.168.1.4:3128(squid) I get simply no HTTP Respond back so nothing works. The same NAT rule works fine, when I configure it on 192.168.1.4 and set this box as the default gateway.
The second bug has nothing to do with squid (it dos not works with or without a transparent squid).
Second. When I configure on 192.168.1.2 the second box (192.168.1.4) as a rulebased loadbalancing gateway and create a firewall rule selecting this gateway for port 80 traffic, the inbound traffic works fine, but the outbound traffic is terribly slow (<1 kb/s) after something like 64 kb. -
Ahh…yeah, you can't do that.
--Bill
-
Ahh…yeah, you can't do that.
--Bill
So, these are no bugs? Both things will not work for now, or will it never work like I desired?
Can you please explain it shortly, especially the 1 kb upload thing?Greetings, techatdd
-
Can I do that, if I add the second wan connection to the first pfsense, running there a squid and then send the squid http traffic with a rule based loadbalancing oer this connection?
-
There are too different bugs:
(Configuration: 192.168.1.2 pfsense Beta3 with a PPPOE Wan Connection as the default gateway and 192.168.1.4 pfsense running squid with a second PPPOE Wan connection.)
First. When I configure a Nat rule on the 192.168.1.2 for redirecting http traffic to 192.168.1.4:3128(squid) I get simply no HTTP Respond back so nothing works. The same NAT rule works fine, when I configure it on 192.168.1.4 and set this box as the default gateway.
You can't redirect to an internal server from inside. With reflection, it might work, but will be horribly slow. PF isn't designed for it and the NAT hooks aren't in the correct place to allow for it. We won't be changing that behaviour, it's a limitation in the OS.
The second bug has nothing to do with squid (it dos not works with or without a transparent squid).
Second. When I configure on 192.168.1.2 the second box (192.168.1.4) as a rulebased loadbalancing gateway and create a firewall rule selecting this gateway for port 80 traffic, the inbound traffic works fine, but the outbound traffic is terribly slow (<1 kb/s) after something like 64 kb.See above. Same problem.
–Bill