Messages

Same/comparable issue on my end. Although my configuration is using DNSBL.

Code Select Expand

2020-12-18T09:20:51 kernel -> pid: 63934 ppid: 1 p_pax: 0xa50<SEGVGUARD,ASLR,NOSHLIBRANDOM,NODISALLOWMAP32BIT>
2020-12-18T09:20:51 kernel [HBSD SEGVGUARD] [unbound (63934)] Suspension expired.
2020-12-18T09:20:51 kernel pid 63934 (unbound), jid 0, uid 59: exited on signal 11

What additional info can I/we append to investigate this issue further? Should we revert to the previous version?

Hi.
No I mean two LANs (em0 and em3) to one WAN (em1)

Hi @Janne

Welcome to the forum!

Judging from the way you asked your question I would presume you are very new to networking. You should probably read up on some routing and switching principles since you seem to be very interested in that.

Now the functionality that you are looking for is explained here >> https://docs.opnsense.org/manual/nat.html#outbound
opnSense does howeve manage this by default so as long as your lan segments (subnets) are properly configured you're g2g.

Basically you can have multiple lan segments share the same outbound gateway or even multiple gateways (gw groups). You will also be able to Layer3 route packets from lan segment a to lan segment b.

Hope this helps to steer you in the right direction. Good luck and reach out when you need a hand!

Confirmed that the issue is fixed after upgrade to version OPNsense 20.1.8_1

Upstream patch is available, couple of weeks to go

Great news && thanks for the update! Let us know if you need testers.

Hey welkom op het forum!  8)

Ziet er een leerrijke opstelling uit voor je.

Wat bedoel je juist met een "WLAN-Ethernet Bridge" ?? Er bestaan "devolo" kits waarmee je een ethernet signaal over je powerline kan sturen. Indien nodig hebben deze vaak ook nog een WiFi AP ingebouwd.

Is dat iets waar je naar op zoek bent om uw madam content te stellen?

Thanks, but that wasn't the key to it. I had heard that 5060 wasn't always UDP. When I look at the live logs and then make a phone call, there is a "default" rule somewhere blocking this port 5060

These logs show you that the destination port is NOT 5060 but some other (prolly) random port. The source port is 5060 though so you should prolly add an extra FW rule to PASS SRC.PORT == 5060.

Is there a way to install ntopng 3.8 ? I believe this version was ok with freebsd

Mimugmail has posted a temporary workaround in this thread to revert to the old version:
If your system is unusable you can always revert to old version via CLI:

Code Select Expand

opnsense-revert -r 20.1.3 ntopng

Your mileage may vary though. On my end the old version on fails after about 5 minutes of runtime.

You should also look into the

Code Select Expand

--ping combined with

Code Select Expand

--ping-restart options. I usually set these to 10 and 60 respectively for S2S ovpn connections.

Feature request added. Thanks.

Please post the link to the request in this thread. I'm also very interested in this feature :)

I'm here :)

Ah good to know you're in the loop and already investigating :D

We will be patient until you provide more feedback. Let us know if we can do some additional tests to assist in solving this.

Hi @all

Issue still present on 20.1.6 with ntop-ng 1.2 and redis 1.1

Not sure if this is related but syslog indicates

Code Select Expand

ntopng: [Utils.cpp:3351] WARNING: ntopng has not been compiled with libcap-dev

ntopng logs does not show any errors.

Is there already a ticket logged for this to the maintainer m.muenz or can we add him to the conversation?

[edit] Removed dev email

Good to hear this solved your issue. At least for now.

Afaick there are 3 ways you can form the logic on FW rules in opnSense.

• Define rule on the interface the traffic is coming into
• Create a floating rule that can be applied before or after all other rules. Depending if the quick flag is activated for the rule
• Create rules on groups of interfaces so that you are not forced to duplicating the rules on every single interface

After that you also need to take into account all the Automatically created rules.

Imho the rule that you are describing should NOT let out any traffic other than traffic generated by the UTM itself. If you have solid prove that this is happening, can deliver traces, and have some time to spare for follow up traces and testing I would suggest creating a bug report so the devs can have a look at it.

I would also be wise to run this issue through the IRC users.

There is only 1 field named "Destination" in the port forwarding config. Study the screenshot below to be spoon fed.



Do note though that this should really be obvious if you have any experience with networking. Study this small diagram and It should become clear on why we are using the WAN as the "Destination" in the PAT rules.

Code Select Expand

External User/App ==> WAN ==> Your opnSense ==> Your Torrent Box

Also read up on this article to clarify what you are configuring.

I hope this helps you in better understanding your configuration.

As a temporary quick workaround you can define a group containing all your VLANS and define an explicit block for inter vlan traffic.

Looking at your NAT rule it looks like you are not forwarding correctly. Destination should be the WAN if address, not the server you are redirecting to. Your live FW log should show you that is the if where the packets are being dropped.

If this does not resolve the issue you should verify the live FW logs and/or run a packet capture on your WAN if to verify the packets are coming through to your end and are not being intercepted/blocked by the ISP.

Keep seeding!