@kiokoman mentionned your best choice : HA-proxy. It will receive traffic for both URLs - unpack the TLS traffic, and, upon detection of the corresponding URL used, send the traffic to the correct internal LA based server. This will cover everything for you except the word 'easy' .... See the YouTube>Netgate>haproxy video - and several others.

Yeah for small amounts of traffic its not all that big of deal, but it sure isn't "optimal" Be like walking to the front door in your house from your bedroom when you want to go kitchen.. vs just going to the kitchen. But lets take for example your plex server sitting right next to your client.. Streaming some movie at XMbps.. Your plex server hands out 2 IPs with plex.tv - it lists your public IP, so that remote clients can talk to your plex server when they are out and about on the internet. But when your client is local, it uses your local rfc1918 address. Which you have to make sure resolves by turning off rebind protection.. If not you would have to nat reflect to get to your own plex server What is better when you say streaming a 20Mbps movie, or lets say multiple streams of that when your watching something, your kids watching something else, and the wife is watching her show on her ipad, etc.. [image: 1601298796472-reflection.png] In your scenario, not only would you be running traffic through pfsense that doesn't need to, you would also be limited by your internet connection speed.

@Derelict Well, I was working with binary, octal & hex long before I even heard of IP, so that may have something to do with it. In fact, one trick I used to use for doing math in my head was to convert to binary, shift as required and back to get a ball park figure. I'd also frequently use logarithms and trig identities, again in my head. Of course, that was several years ago, but I'm still fairly sharp with logs.

Hey Rob, you're right. I am on two different subnets. 192.168.0.0/24 and 192.168.1.0/24 so i need routes on both sides.

with LACP enabled with two interfaces ping and dns not responding. If i deactivate this, all working

@Blachawk said in So Many IPs - How to get them all?: Thank you all for your responses. It does seem to be a daunting task. Nothing nefarious going on. We are dropping analog TV as are many providers, to free up frequency for OFDM with the new Docsis 3.1. We still have many TV only customers and telling them they have no choice but to purchase internet now is not very palatable. In some areas there are even franchise issues that dictate we provide a TV only package. Also giving them Internet for free isn't the worst thing we could do but it would be better to give what's paid for and offer an upgrade path if they want it. I may indeed have bitten off more than I can chew but who doesn't enjoy a good project? It appears that I will have to break out wireshark again and look closer at port use rather than IP. Again, Thanks for responding. Ah, so you are a Cable Television/Internet provider. That was not 100% clear from your previous posts. Sounded more like an apartment complex setup or something.

FIXED. The issue was with the remote subnet. I set it to address instead of /30 network after stumbling on your Routed-IPsec slides from 2018 hangout. [image: 1600803921184-0457a3e0-0739-481a-b572-0be5819b3a31-image.png] With GW monitoring working, my FW rules with specified GW instantly started working. Can you confirm that these rules get ignored even when GW-mon is manually disabled? Thanks.

I HAVE FOUND THE SOLUTION AND THE SOURCE OF MY PROBLEM EVERYBODY: TO ANYONE ELSE WHO HAS AUDIO CALLS BEING BLOCKED, THE ANSWER IS THIS: telegram has a set collection of servers/hosts as we all know, what I DIDNT know is that apparently telegrams audio calls use UDP ports (I didnt do exact math, but just lumped the combination of ports I had collected logs from to a lump of 100) 500-600 on UDP to make/connect the calls! SO the answer was allow telegram's servers UDP access to ports 500-600 just to lump it up and get it working and it connected right off the bat this time! SUCCESS

Hi, I configured this rule only to test floating rules. If I understand, this rule should allow outgoing requests from the WAN ip to any UDP port 53 destination. What confuses me is that enabling this rule, the access DNS from the client does not work. Thanks

see here why do not use schedeule for block rules ! so this is solved. https://forum.netgate.com/topic/156963/scheduled-block-rule-does-not-seem-to-block-existing-established-connections/5?_=1600535854178

@Derelict thank you !

OK you installed an manual service/proxy on pfSense that listens on 7892. Sooo what now? You wanna connect to it via WAN? Then just add a port forward rule with destination "WAN address" (or whatever IP on WAN you want to use) and as redirect IP use 127.0.0.1. With port 7892 of course. Anything else traffic wise would be from the proxy itself to <whereever> and would be allowed outgoing coming from "localhost". It's nearly the same as having OpenVPN configured to listen to localhost instead of a WAN and just port forwarding it to localhost/udp1194 - that is done in MultiWAN configurations all the time. :) That should do it: [image: 1600553478204-5cef4d80-df8e-4118-bf73-bcd59cb57799-image.png] With the "Add assoc. filter rule" there should be a rule on WAN allowing the traffic, too. So you should be set.

On these policy: [image: 1600460597784-2c192778-e862-4407-aabb-16ee7ee3770e-imagen.png] On "0/0 B" : [image: 1600460583575-037d0f15-f784-49b6-a181-0f33deeef610-imagen.png] That's weird, i never use it Yes, the interface on the policy is correct Is this 10.13.0/24 network downstream network? Yes , there are hops to an MPLS, no directly attached, no NAT used by us (asking to ISP ), and pfsense cant reach to it. [image: 1600461313334-df14c6e2-3ad0-4f40-af72-626a18810182-imagen.png] From 10.13.0.20 -> to 8.8.8.8 [image: 1600461623868-eb0363d9-43c0-4776-9177-56bb21943b71-imagen.png] I take it the actual problem is this 10.13.0.20 is trying to ping 8.8.8.8 and you get no answer? 10.13.0.20 no reach 8.8.8.8 because its cut in pfsense Sorry me english and if i'm not clear in something Thanks

@butterchicken That would require deep packet inspection. The URL is part of the HTTP header, but beyond that, no. As I understand it, Google often uses the same IP addresses for the various services, so you couldn't filter on that.