Project

General

Profile

Bug #9524

HAProxy-Backend blocks routed vlan traffic

Added by Jonas Bechtel over 1 year ago. Updated over 1 year ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/14/2019
Due date:
% Done:

0%

Estimated time:
Affected Version:
Affected Architecture:

Description

Hi everybody,
we have a weird haproxy-backend problem. HAProxy-backends seems to block routet traffic between two connected vlans, on the configured port.
Following is our setup:

VLAN1: Range: 192.168.40.0/22
VLAN2: Range: 192.168.47.0/24

Client1: 192.168.47.20
Mailserver: 192.168.42.3

Client1 want to reach directly, without the haproxy, the mailserver on the ports 993 and 465.
The Haproxy have a frontend and backend on the ports 993 and 465.

My test is a telnet session from Client1 to the mailserver over the ports 993 and 465. Boths tests are running into a timeout.
A telnet test to the port 143 to the mailserver gets an answer. All other listening ports from the mailserver can be reached, without the haproxy ports.
To make a negative test, I created a haprox-backend for port 143 to 192.168.42.3. After applying this change, I can't get a connection to port 143. After deleting the backend, connections are again possible.
Hint: The backend wasn't even in use from an frontend.

The interesting thing is that only the return packets get stuck in the firewall. Package recordings show on the client1 connections to the mail server, on the firewall connections from client1 to the mail server (no reply packages from the mail server to the client1) and on the mail server packages from client1 to the mail server and packages from the mail server to the client1.

Screenshot from 2019-05-14 14-46-28.png (34.2 KB) Screenshot from 2019-05-14 14-46-28.png HAProxy 993 backend Jonas Bechtel, 05/14/2019 08:08 AM
Screenshot from 2019-05-14 14-47-15.png (15 KB) Screenshot from 2019-05-14 14-47-15.png HAProxy 993 frontend Jonas Bechtel, 05/14/2019 08:08 AM
Screenshot from 2019-05-14 14-55-22.png (13.6 KB) Screenshot from 2019-05-14 14-55-22.png HAProxy 465 frontend Jonas Bechtel, 05/14/2019 08:08 AM
Screenshot from 2019-05-14 15-05-54.png (114 KB) Screenshot from 2019-05-14 15-05-54.png Client1 ip address/connection tests Jonas Bechtel, 05/14/2019 08:08 AM
Screenshot from 2019-05-14 15-11-57.png (28.4 KB) Screenshot from 2019-05-14 15-11-57.png HAProxy 465 backend Jonas Bechtel, 05/14/2019 08:12 AM

History

#1 Updated by Jim Pingle over 1 year ago

  • Project changed from pfSense to pfSense Packages
  • Status changed from New to Not a Bug

This is almost certainly a configuration issue, and this site is not for support or diagnostic discussion.

For assistance in solving problems, please post on the Netgate Forum or the pfSense Subreddit .

See Reporting Issues with pfSense Software for more information.

If a specific bug is located, an issue can be opened for it at that time with more detail.

#2 Updated by Pi Ba over 1 year ago

Its likely because of transparent-client-ip feature enabled in the backend of haproxy, combined with the 'bug' / missing feature in pf that it doesn't support divert-reply rules (or something similar.) , so the ipfw fwd rule sends ALL reply traffic to localhost>haproxy for this to work at all..

Best workaround is probably to configure a second port or second IP-address on the backend server for exclusive use by haproxy..

@Jimp would you have any option to ask someone/anyone to implement the feature in 'pf' ? I gave it a try adopting a previously existing patch but Ermal didn't like that way.. quite a few years ago he was going to do it a better way which is out of my league of modifying, but i don't think it ever happened..
- https://lists.freebsd.org/pipermail/freebsd-bugs/2014-April/055823.html
- https://lists.freebsd.org/pipermail/freebsd-net/2009-June/022166.html
- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188511
- https://lists.freebsd.org/pipermail/freebsd-net/2015-August/043178.html

#3 Updated by Jonas Bechtel over 1 year ago

Hi guys,
thanks for your answers.
I didn't recognize the warning above the the "Use Client-IP" feature. I am sorry for that. Its just confused me so much, that the haproxy/pfsense answers packages, that are not intended for them. Sorry for that ticket!

Also available in: Atom PDF