Project

General

Profile

Actions

Bug #8761

closed

Port Forwarding Rules Stop Working when HAProxy is Configured

Added by Acat L over 5 years ago. Updated over 5 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
haproxy
Target version:
-
Start date:
08/07/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
2.4.3_1
Affected Plus Version:
Affected Architecture:
amd64

Description

HAProxy version: 1.7.11
pfSense version: 2.4.3-RELEASE-p1 (amd64)
built on Thu May 10 15:02:52 CDT 2018
FreeBSD 11.1-RELEASE-p10

I have Port Forward rules that are tested and running. When HAProxy is started (i.e. after configuration FE/BE), all Port Forward rules stop working. All configured ports of the Port Forward rules stops working even within shell. It will only work again when HAProxy package is uninstalled.

I've been able to reproduce it 5x already. It specifically occurs when a new BE is created. Here's further info

My setup has 2 test NATs (forwards to 80/443 on 1 host on the LAN zone). They're perfectly working fine. HAProxy also starts up fine when no BE/FE configured. Everything is in default. But when a new BE is configured which points to the same 1 host:port on the LAN zone, NAT rules suddenly stop working. Rebooting pfsense doesn't do the trick. NAT rules works again only when removing the BE and rebooting pfsense, or when uninstalling haproxy package and then rebooting.

Issue doesn't happen on my production setup with haproxy 1.7.4 on pfsense 2.3.4-Release-p1.

Actions #1

Updated by Jim Pingle over 5 years ago

  • Status changed from New to Duplicate

Duplicate of #8760

Please post on the forum or pfSense subreddit to discuss the problem.

Actions #2

Updated by Acat L over 5 years ago

Jim Pingle wrote:

Duplicate of #8760

Please post on the forum or pfSense subreddit to discuss the problem.

How many times to do i need to deploy a new pfsense, setup it up, and test again, in order to legitimise this as a bug?

Actions #3

Updated by Jim Pingle over 5 years ago

That's a question that can only be answered by discussing the issue on the forum or the pfSense subreddit.

Actions #4

Updated by Acat L over 5 years ago

Jim Pingle wrote:

That's a question that can only be answered by discussing the issue on the forum or the pfSense subreddit.

Oh, so the process of bug reporting for pfSense is that it has to undergo discussion over reddit before such reports are taken seriously?

Actions #5

Updated by Jim Pingle over 5 years ago

When they can't be reproduced as stated, yes. See https://www.netgate.com/docs/pfsense/development/bug-reporting.html

Actions #6

Updated by Tj Ng over 5 years ago

ACat L. Check your HAProxy's advanced settings. Turn off "Transparent ClientIP" and see if NAT works again.

Captive Portal + HAProxy + NAT all seem to mess around the IPFW in some shape or form. Using just 1 is fine, using them all in one box looks too problematic for now.

Actions #7

Updated by Acat L over 5 years ago

Tj Ng wrote:

ACat L. Check your HAProxy's advanced settings. Turn off "Transparent ClientIP" and see if NAT works again.

Captive Portal + HAProxy + NAT all seem to mess around the IPFW in some shape or form. Using just 1 is fine, using them all in one box looks too problematic for now.

Thank you for looking into this Tj. I didn't expect someone will look into this issue after having been adamantly dismissed.

For the record, nope, I was using only HAProxy & NAT/PF on my implementation that time, and without Captive Portal, but yeah, there seems to be something that's messing with IPFW when HAProxy & NAT are both enabled on my setup and the subsequent tests I did.

It's been sometime ago, so I can't remember if I did play around dis/enabling "Transparent ClientIP" in my tests. But in my production setup at the time of the bug report (i.e. my production being on haproxy 1.7.4 on pfsense 2.3.4-Release-p1), "Transparent ClientIP" was enabled and was completely working fine, but wasn't the case come HAProxy version: 1.7.11 on pfSense version:2.4.3-RELEASE-p1 (amd64). Hence, the bug report, but was ultimately ignored.

Actions

Also available in: Atom PDF