[Inbound load balancing / server load balancing / relayd] configuration

eri--

Is it working or not for you?

DSR is a very specific type of configuration not usually used.

hikeonpast

John,

Thanks for your reply. There doesn't seem to be much information available on this subject, so I appreciate you sharing your success. I see what you mean about DSR behind the fw only.

In doing packet sniffing with our relayd configuration, we're seeing the client IP show up at the backend server. Because the backend servers are dual homed (one DMZ, one LAN), we're having routing issues in that the default gateway is on the LAN side. The public IP comes through relayd to the backend server via the DMZ and the server wants to reply to it through the LAN port.

Can you share any details on the routing configuration of your backend servers?

Ermal,

It is not working for me due to the routing issue described above.

Cheers,

Dean

eri--

Than you need DSR yourself :)

Can you please describe your setup better is not clear for me!?

jwelter99

Our http and https back ends live in the DMZ only. PF has a public, DMZ, and LAN interface. PF is setup to allow only http and https from public->DMZ IP of back ends.

The back ends use the PF sense DMZ IF IP as the gateway (and also DNS and NTP as we run those services on PF).

We run 2 PF boxes and the public, DMZ and LAN IP we use is a CARP so if a PF box goes down we fail over.

For the http and https back ends to get to the LAN (DB and NFS) they traverse the PF boxes to do this. We have rules set to allow this only from the DMZ IP's -> LAN IP's required.

This has proven to be a simple and secure setup, that scales well for our use. We do have a risk that if someone compromises the firewall to DMZ they could get LAN access from the back ends but from my past experience more complex network topologies are not always more secure due to complexity and human error.

PFsense on mid range hardware has no issues handling the traffic.

We also use countryblock to help cut down the intrusion attempts.

John

@hikeonpast:

John,

Thanks for your reply. There doesn't seem to be much information available on this subject, so I appreciate you sharing your success. I see what you mean about DSR behind the fw only.

In doing packet sniffing with our relayd configuration, we're seeing the client IP show up at the backend server. Because the backend servers are dual homed (one DMZ, one LAN), we're having routing issues in that the default gateway is on the LAN side. The public IP comes through relayd to the backend server via the DMZ and the server wants to reply to it through the LAN port.

Can you share any details on the routing configuration of your backend servers?

Ermal,

It is not working for me due to the routing issue described above.

Cheers,

Dean

hikeonpast

John, thanks.

Ermal, apologies. See below.

Remote management via VPN to the LAN. Load balanced HTTP/HTTPS requests come into the DMZ. I currently have the LAN as the default gateway, which causes issues for serving since the packets try to leave the webserver via the LAN. Changing the default gateway to the DMZ fixes the web packet routing issue, but causes problems for the other services that we're running on the LAN.

(There are other nodes on the LAN which are omitted for clarity)

Thanks,

Dean

hikeonpast

Side question related to my original post:

In looking at the auto-generated relayd.conf file, I note that for each redirect section there are two identical forward to entries, each with a load balancer entry. From looking at my webserver logfiles, this appears to generate two check pings per cycle. Not a huge deal, but just wondering if this is intentional.

redirect "CCG_VIP" {
  listen on <publicip> port 443
  forward to <ccg_ssl> port 443 check https '/loadbalance.html' host <pubhost.net> code 200 timeout 1000
  forward to <ccg_ssl> port 443 check https '/loadbalance.html' host <pubhost.net> code 200 timeout 1000
}</pubhost.net></ccg_ssl></pubhost.net></ccg_ssl></publicip>

Cheers,

Dean

jwelter99

FYI: I don't have this in our config…..

I also just tried on a VM deployment of PF 2.0 RC current build and on a test lbha config don't see it either.

@hikeonpast:

Side question related to my original post:

In looking at the auto-generated relayd.conf file, I note that for each redirect section there are two identical forward to entries, each with a load balancer entry. From looking at my webserver logfiles, this appears to generate two check pings per cycle. Not a huge deal, but just wondering if this is intentional.
redirect "CCG_VIP" {
  listen on <publicip> port 443
  forward to <ccg_ssl> port 443 check https '/loadbalance.html' host <pubhost.net> code 200 timeout 1000
  forward to <ccg_ssl> port 443 check https '/loadbalance.html' host <pubhost.net> code 200 timeout 1000
}</pubhost.net></ccg_ssl></pubhost.net></ccg_ssl></publicip>
Cheers,

Dean

eri--

I do not think the present load balancer can do DSR.
So either you contact pfSense comercial support to implement DSR, since it is not planned for 2.0, or keep the default gateway at DMZ and provision for the other services.

hikeonpast

Hi,

Thanks for your response. To be clear, I don't want DSR.

I was initially asking why PFS uses the redirect directive, which seems a lot like DSR behind the firewall. I was wondering if the relay directive might be a good choice to do more traditional load balancing (i.e. where the public IP source address is NATted to the IP of the load balancer as it is passed to the backend server…and if PFS supported it.

Thanks!

-Dean

eri--

Ah that can be provided from HAproxy.
I do not think/know relayd can do such thing!