Port Forwarding matching too widely ? DestinationInvert LAN_net

Started by toxic, October 15, 2020, 01:53:41 AM

Previous topic - Next topic
Quote from: toxic on October 24, 2020, 04:45:30 PM
also, sorry, I think what works or not has not been made clear :
Works :
- client query piHole direcly and pihole reports proper client IP
- client query 1.1.1.1 and gets blocked
Does not work :
- client query 1.1.1.1 and piHole responds instead

In this last case that does not work, I really don't care much about what IP piHole sees, I'll find some log files somewhere to report on this trafic later finding out who is refusing to use the DNS provided by my DHCP ;) I'd just like to not break the working points :D.

Sorry if I'm not getting your point here. In your opening post you wrote, if you enable that rule, clients that try to connect to an outside DNS (like 1.1.1.1) are getting port forwarded to the piHole but the piHole sees the wrong source IP (OPNsense IP). Correct?

In your last post you wrote this is not working. If your client is trying to reach 1.1.1.1@853 (DoT) you cannot port forward this connection.

Client F (10.0.0.50) ----> 1.1.1.1@53 (DNS) ---> OPNsense (default gateway) --> rule says to rewrite that destination to 10.0.0.6 WITH source rewritten OPNsene IP
piHole gets the query and sends the packet back to OPNsense (source) and OPNsense sends the answer back to Client F

Without source rewrite:
Client F (10.0.0.50) ----> 1.1.1.1@53 (DNS) ---> OPNsense (default gateway) --> rule says to rewrite that destination to 10.0.0.6 WITHOUT source rewritten OPNsene IP
piHole gets the query and sends the packet directly to Client F (because that is the source piHole was told) --> Client F discards that packet, because Client F doesn't know anything about that query towards piHole

With piHole or client in a different subnet:
Client F (10.0.0.50) ----> 1.1.1.1@53 (DNS) ---> OPNsense (default gateway) --> rule says to rewrite that destination to 10.0.1.6 source would not be rewritten
piHole gets the query sees the correct IP of Client F and sends the packet back to OPNsense (gateway) and OPNsense forwards the answer to Client F

,,The S in IoT stands for Security!" :)

Thanks a lot, i'll give that a try !
Not sure yet how to go around with 2 subnets 10.0.0.0/24 and 10.0.1.0/24, have LAN be on 10.0.0.0/16 or leave LAN on 10.0.0.0/24 and create another LAN2 for 10.0.1.0/24... Will try out a few things, starting simple with an extra virtual interface.

Sorry for all the going back and forth, I did try out lots of things and changed the status from my first post.
So while I'm trying out the new subnet, maybe you can still help me understand, because I'm still in the dark...

Let say current situation is with no special NAT rule enabled :
1/ - 10.0.0.50 queries DNS 10.0.0.6 directly : normal net routing, 10.0.0.6 sees the request from 10.0.0.50
2/- 10.0.0.50 queried DSN 1.1.1.1 directly : beeing NATed to my WAN interface, got the proper reply from CloudFlare
Now I'd like to understand why I cannot find a NAT rule that I would add and would allow :  this :
3/ - 10.0.0.50 queries DNS 10.0.0.6 directly : normal net routing, 10.0.0.6 sees the request from 10.0.0.50
4/ - 10.0.0.50 queried DSN 1.1.1.1 directly , go through 10.0.0.1 that rewrites to 10.0.0.6 and NAT it putting itself as origin. 10.0.0.6 sees query from 10.0.0.1, reply, and opnSense re-NAT the reply to the client

Any single NAT rule I've tried has only allowed me to do half of it : either I do a NAT rule that never matches and 3/ keeps working as it was in 1/ but 4/ never works. And if I try harder and do a NAT rule that matches, it always matches "too widely" and I do get 4/ working, but 3/ is not working, instead I see this 5/ :
5/  - 10.0.0.50 queries DNS 10.0.0.6 directly : go through 10.0.0.1 anyway due to physical needs, and despite the NAT rule saying "source is NOT in LAN net" it still rewrites to 10.0.0.6 and NAT it putting itself as origin. 10.0.0.6 sees query from 10.0.0.1, reply, and opnSense re-NAT the reply to the client. So the client gets the answer, but the DNS has seen a NATed packet where there was no need to NAT it and actually the rule said it should not be a match :(

Still that baffles me... I will definitely give it a try with another subnet, but if I put anything else than my DNS on this subnet, the same issue will arise... For now I understand that it might simplify my setup and I will  give a subnet to my DNS alone, maybe would like to use it for my servers in the future and avoiding the same issue again would be nice ;)

damn it ! you were right !
I still don't understand why my first attempt won't work, but with a second subnet, I have it working, and the piHole sees the source IP regardless of if it was spoofed or not, the NAT rule actually does not rewrite the source adress at all...

I mean, with my old NAT port forward rule and piHole on the same subnet as the client, when client asks pihole directly, I understand that if opnSense rewrites the target IP from 1.1.1.1 to 10.0.0.6 without NATing itself in the src address, it will probably not see the response come back, but it is realy not an issue for me, it should not put itself in the src...

So, first and foremost : thanks for showing me how it's done properly that is with different subnets. It pains me to have to dedicate one subnet to my DNS only sadly... Going through the troubles of creating yet another interface, subnet and the FW rules to go with it... I would have liked to isolate my servers from the clients as well. But if I put my servers on the same subnet as the DNS, I'll have the same issue if I want to spoof the DNS for my servers...

This turns into new questions for me now that I'm considering having different subnets... Is there a way for me to have several subnets on the same bridge ? Or can I combine things like my LAN10 that is "only" subnet 10.0.10.1/24 and have some other LAN interface that is on 10.0.0.1/16 to which I connect hosts that are on 10.0.0.0/24 for some of them and others on 10.0.10.0/24 or even another on 10.0.123.0/24 ?

Again, thanks for your kind help and patience in helping me try to understand the mess I made ;)

Quote from: toxic on October 25, 2020, 12:18:18 AM
This turns into new questions for me now that I'm considering having different subnets... Is there a way for me to have several subnets on the same bridge ? Or can I combine things like my LAN10 that is "only" subnet 10.0.10.1/24 and have some other LAN interface that is on 10.0.0.1/16 to which I connect hosts that are on 10.0.0.0/24 for some of them and others on 10.0.10.0/24 or even another on 10.0.123.0/24 ?

Again, thanks for your kind help and patience in helping me try to understand the mess I made ;)

Never include subnets in a wider subnet. Every interface has its own subnet, don't mix it. Traffic passing from one subnet to another will run through your OPNsense.
,,The S in IoT stands for Security!" :)