IRC Request are blocked by Default Deny

[PaulePils]

Hello,

when I started locking down my opnsense (Adguard, IPS, Zenarmor), I noticed that IRC/DCC request suddenly get blocked. After checking the IPS, Zenarmor logs I found no entry.
So, I created an alias with the known IRC ports (6660:6669) and a pass rule in the LAN interface (screenshot) but it still got blocked.
In the Log LiveView, I saw that the source port is something completly different, something in the dynamic area 5xxxx and not something between 6660:6669. Is this a normal behaviour?

After some reading I tried a NAT Port Forward rule with source port any to destination port IRC Alias. Then it worked but it doesn't sound very safe to open all ports to the internet.

I want to learn where I did it wrong and how I can improve it.

[CJ]

Source ports are generally random.  The ports specified for various services are the destination ports.

[PaulePils]

That means the the Alias itself should be fine.
But should it be handled as a port forward rule or a rule in WAN/LAN/both?

[CJ]

Post a pic of the live view showing the blocking.

[PaulePils]

I attached the Screenshot of:

• the LiveView unblocked (rule enabeld)
• the LiveView blocked (rule disabled)
• the LAN rule (the interface has a different name but it is LAN)
• the Alias with the known ports of IRC

[CJ]

Based on this page, you don't need half of those ports in the IRC alias.  Just the following.
113, 194, 6660-6669 and 6697

I assume LAGG_Switch is your LAN or is it untagged?  Did you use HomeNetworkGuy to configure things?

Remove the Source ports.  There's almost never a need to click that Advanced button.  You can leave your Source set to LAGG_Switch net if you want but since the rule is already being applied only to the LAGG_Switch interface it's kind of redundant.

Leave your Destination as any.  You can set it to not private networks or something similar if you want to prevent machines on LAGG_Switch from hitting other local network subnets.  Set Destination Ports to IRC.

After that it should work the way you want.

[PaulePils]

"LAGG_Switch" is the parent interface for my vlans. I first started with guest, IoT, work in vlans but could move the rest because I need to change my homeserver first. (and I currently don't have the time to do this)

I tried it like you said but unfortunatly it is still blocked by the "default deny" rule...

From what I have read about a DCC request it first sends a message out to owner of the file. So the first interaction comes from my side. So i tried the same rule but in "out"- direction... nothing. Then with WAN as source to destination "any"... still nothing.
Am I missing something?

[CJ]

Yes.  The directions are in regards to the interface.  An Out rule on LAGG_Switch is acting on traffic leaving the OPNSense interface and heading out to your switch.

Why are you talking about DCC?  Does IRC itself work?  What does your Live View show?

Where are your clients located?  What VLANs, etc?  Do you have a network diagram?

[PaulePils]

I attached a quick network diagramm. The client in question is the PC in the LAGG_Switch network.

The IRC channel itself are working, so i can send and receive messages in the channels. But if I make a DCC request, there is a timeout. The LiveView is the same as the screenshot.
First I thought it has something to do with Suricata or Zenarmor but there is nothing. I only get a connection when I activate the NAT forward rule to allow any source port to the destination IRC alias.

[CJ]

No idea what a drawio extension is.  Can you post it as a picture?

What rules do you have configured when IRC works and DCC does not?

[Patrick M. Hausen]

DCC is a file transfer mechanism on top of IRC that needs a direct data channel between both parties similar to FTP. Difficult behind NAT devices and firewalls. The OP probably needs to port-forward a certain range from their external address to their PC. I don't know if DCC for multiple devices behind a NAT is possible at all. These are protocols from the stone age of the Internet. BTDT.

That's what I remember from the top of my head. More detailled help would require more research on my part, so for now I'm just bouncing these hints back to you.  ;)

[CJ]

DCC is a file transfer mechanism on top of IRC that needs a direct data channel between both parties similar to FTP. Difficult behind NAT devices and firewalls. The OP probably needs to port-forward a certain range from their external address to their PC. I don't know if DCC for multiple devices behind a NAT is possible at all. These are protocols from the stone age of the Internet. BTDT.

That's what I remember from the top of my head. More detailled help would require more research on my part, so for now I'm just bouncing these hints back to you.  ;)

Yeah, I haven't dealt with DCC before.  I'm just trying to understand what they currently have configured, what is and isn't working, etc.  People love to twiddle 15 different knobs and only tell you about one.

[PaulePils]

DCC is a file transfer mechanism on top of IRC that needs a direct data channel between both parties similar to FTP. Difficult behind NAT devices and firewalls. The OP probably needs to port-forward a certain range from their external address to their PC. I don't know if DCC for multiple devices behind a NAT is possible at all. These are protocols from the stone age of the Internet. BTDT.

That's what I remember from the top of my head. More detailled help would require more research on my part, so for now I'm just bouncing these hints back to you.  ;)

Yeah, I haven't dealt with DCC before.  I'm just trying to understand what they currently have configured, what is and isn't working, etc.  People love to twiddle 15 different knobs and only tell you about one.

Yeah that sounds like me :-D  trying to much stuff in the same time..... if I have some....  ::)

DCC is a file transfer mechanism on top of IRC that needs a direct data channel between both parties similar to FTP. Difficult behind NAT devices and firewalls. The OP probably needs to port-forward a certain range from their external address to their PC. I don't know if DCC for multiple devices behind a NAT is possible at all. These are protocols from the stone age of the Internet. BTDT.

That's what I remember from the top of my head. More detailled help would require more research on my part, so for now I'm just bouncing these hints back to you.  ;)

That's what I thought. It is quite old but at the same time it is quite fast.

Regarding the security risks: If I open all ports on the source but only some on the destination what will an attacker see? Open doors? Slightly open doors? Nothing unless the connection is used?
I am trying to understand what would happen because I don't need a firewall if I open everything up just out of convenience ::)

[CJ]

Regarding the security risks: If I open all ports on the source but only some on the destination what will an attacker see? Open doors? Slightly open doors? Nothing unless the connection is used?
I am trying to understand what would happen because I don't need a firewall if I open everything up just out of convenience ::)

I think we're you're getting confused is with the whole source and destination bit.  Unless you are controlling the other site and client, you're not doing anything to the destination.  All ports and changes are regarding you only.

Whether something is inbound or outbound all depends on where you're looking at.  It's like looking in a mirror and can be confusing.

A request from your browser to a website is outbound from your machine.  But it's inbound to the OPNSense interface and firewall.  Once it's processed by OPNSense that request is then outbound from OPNSense and inbound to the website.

The website replies with the web page.  That goes outbound from the website and inbound to OPNSense and the firewall.  Normally it would be dropped, but the firewall knows that you just asked the website for some data and therefore allows the web page.  The web page then moves outbound from the OPNSense interface and inbound to your browser.

The default deny inbound to OPNSense from the internet protects you from the literal zombie horde out there.  The default allow outbound to the internet from OPNSense makes it so things generally work and every user doesn't have to constantly call tech support.

If you want to open ports and allow the internet to directly connect, you should put any machine that does so in a DMZ that's blocked off from your internal LAN.  That way if you do screw up and get hacked, they only can get access to what's in the DMZ.

[PaulePils]

Thanks for the example. This is one of the best "picutre" that I read about the whole inbound/outbound logic and makes it easier for me to understand all of it :-)

I will tinker with this (and all my other stuff) keeping your example in mind and consider this thread as solved.

Thanks for all your time and input.