Hi Willy,
Thanks the patches look good, and when applied separately all compile
without issues on FreeBSD. (Except when using the USE_LINUX_TPROXY flag,
but that shouldn't be used on FreeBSD anyway.)
And transparent proxying works correctly on FreeBSD as was expected.
Ive included a
Hi Willy,
Could you please let me know what your findings are about the proposed
patch?
Does it need some more work, is it implemented wrongly, or would it help
if i send my current haproxy.cfg file?
If i need to change something please let me know, thanks.
Thanks for your time,
PiBa-NL
Op
Hi,
On Wed, May 08, 2013 at 07:34:19PM +0200, PiBa-NL wrote:
Hi Willy,
Could you please let me know what your findings are about the proposed
patch?
I was on it this afternoon (didn't have time earlier) :-)
I haven't finished reviewing it yet, because I was trying to figure if
there would
Hi Willy,
If you make some changes to what you think/know is better and break the
change into two parts is fine for me.
About calling setsockopt multiple times, i think the ret |= would not
evaluate the call behind it if ret already is 1, not absolutely sure
about that..
I didn't think of
Hi,
On Wed, May 08, 2013 at 09:41:33PM +0200, PiBa-NL wrote:
Hi Willy,
If you make some changes to what you think/know is better and break the
change into two parts is fine for me.
OK.
About calling setsockopt multiple times, i think the ret |= would not
evaluate the call behind it if
p.s.
Ive spotted a issue in my patch with the IPv6 part where i forgot about
the OpenBSD part (SOL_SOCKET SO_BINDANY) should probably be added
there also.
No problem, we'll add this as a third patch. It's really important to
have one feature per commit, because when for some reason
OK here's what I came up with. There are 3 patches :
- 0001 : reorganize flags processing
- 0002 : add support for freebsd
- 0003 : add support for openbsd
Please review and test if you can. At least it seems OK on linux here.
I have written all the commit messages. Feel free to change
Hi Willy,
It seams the changes where easier than i expected, assuming ive done it
'correctly'...
I generated 2 patch files:
-FreeBSD IP_BINDANY git diff.patch generated with a git diff (against
a hopefully relatively recent source tree)(i couldnt get it to fetch
Hi,
On Fri, Apr 26, 2013 at 12:55:23AM +0200, PiBa-NL wrote:
Hi All / Developers,
Seams i have tranparent proxying working now on FreeBSD 8.3 with
HAProxy1.5dev18 + small modification.
Needed to add a firewall forwarding rule to forward the traffic to the
localhost for socket processing.
Hi Willy,
Sorry for the weird syntax.. I made the text 'bold', but that seams to
have come out differently...
Anyway i hope the 'patch' below is something you can work with.?
As for renaming the CONFIG_HAP_LINUX_TPROXY to something different would
require everyone that on a regular basis
Hi,
On Fri, Apr 26, 2013 at 08:40:49PM +0200, PiBa-NL wrote:
Hi Willy,
Sorry for the weird syntax.. I made the text 'bold', but that seams to
have come out differently...
As you can guess, there is no bold attribute in source code, so it
must necessarily appear differently at some point.
Now that I'm seeing the patch in its context, I think it's not the
cleanest way to do it, because we redefine IPV6_TRANSPARENT and
IP_TRANSPARENT when IP_FREEBIND is not defined, while we don't use
this one and the other ones are defined below. Also I'm concerned
about the result of running this
Hi,
throwing in my two cents here, based on a few uneducated guesses reading
the Makefile, etc. Feel free to disagree/correct/shout at me :)
(actually I wrote this before Willy answered)
As for renaming the CONFIG_HAP_LINUX_TPROXY to something different would
require everyone that on a
Hi Lukas,
On Fri, Apr 26, 2013 at 10:26:33PM +0200, Lukas Tribus wrote:
Hi,
throwing in my two cents here, based on a few uneducated guesses reading
the Makefile, etc. Feel free to disagree/correct/shout at me :)
Thanks for sharing your thoughts, I feel less alone sometimes when I can
Hi Willy / Lukas,
It seams to me OpenBSD doesn't support the IP_BINDANY flag..:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet/in.h
http://www.openbsd.org/cgi-bin/cvsweb/%7Echeckout%7E/src/sys/netinet/in.h
While FreeBSD does:
On Fri, Apr 26, 2013 at 11:03:00PM +0200, PiBa-NL wrote:
Hi Willy / Lukas,
It seams to me OpenBSD doesn't support the IP_BINDANY flag..:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/netinet/in.h
http://www.openbsd.org/cgi-bin/cvsweb/%7Echeckout%7E/src/sys/netinet/in.h
it seems
Hi Willy,
Ill give it a try and send the patch as an attachment, though im not
100% comfortable with the code. I think i can do it.
Will take me a few days though..
Thanks sofar.
Op 26-4-2013 23:12, Willy Tarreau schreef:
On Fri, Apr 26, 2013 at 11:03:00PM +0200, PiBa-NL wrote:
Hi Willy /
Hi All / Baptiste,
It seams i have found error in my initial email sorry for that. It
should have mentioned IP_BINDANY in the example line of code instead of
IP_FREEBIND. Still the my problem remains the same.
Returning SYN-ACK packets are not recieved/intercepted by HAProxy. And
the
Hello HAProxy developers/users,
I would like to be able to run HAProxy transparently on FreeBSD 8.3.
This would be both for my own usage and also to make it available to a
larger public by including it in a 'haproxy-devel' package for pfSense.
However when trying to use it i get the error:
I forgot to mention im using HAproxy 1.5dev18.
Hello HAProxy developers/users,
I would like to be able to run HAProxy transparently on FreeBSD 8.3.
This would be both for my own usage and also to make it available to a
larger public by including it in a 'haproxy-devel' package for pfSense.
Hi,
In order to work in transparent proxy mode, the server's default
gateway must be the HAproxy server.
Or at least, the traffic from the server must pass through the haproxy
box before reaching the client.
Even if HAProxy spoof the client IP, it's HAProxy which initializes
the TCP connection,
Hi Baptiste,
Thanks for your reply, i understand that the traffic must pass through
the router/HAProxy box, and for that part i can confirm that the routing
of packets is 'working' like it should.
To explain my setup a little more:
*Webserver* (Win7) 192.168.0.40/24 on a OPT1/DMZ using
22 matches
Mail list logo
