Messages

1

23.1 Production Series / Re: Security issue with syncookie sequence numbers

« on: May 28, 2023, 04:49:12 pm »

On reflection, with Opnsense acting as a firewall, I do not think that it makes sense for Opnsense to apply syncookies to forwarded connections.  It certainly seems odd.

When I enabled syncookies, I was thinking that it would be applied only to services running on the firewall itself - it never occurred to me that it might also apply it forwarded connections.

2

General Discussion / Re: All meta sites are blocked?!

« on: May 28, 2023, 03:11:35 pm »

I had the same problem which I resolved by disabling syncookie:

Code: [Select]

Firewall->Settings->Advanced->Enable syncookies = none
See my post https://forum.opnsense.org/index.php?topic=34237.0

3

23.1 Production Series / Facebook owned sites blocked when syncookies are used.

« on: May 28, 2023, 02:58:18 pm »

Facebook owned sites, including whatsapp.com, are effectively blocked when setting:

Code: [Select]

Firewall->Settings->Advanced->Enable syncookies = always
No other site seems to be affected.

Using Wireshark on the WAN connection from my Opnsense box to my modem shows that, with syncookies enabled, no response is obtained from facebook owned sites for the transmitted Opnsense reconstructed SYN.

I do not know whether facebook et al object to the constant tcp sequence number of 64240 as reported  here: https://forum.opnsense.org/index.php?topic=34236.0 or because  tcp options are removed from the SYN by the syncookie mechanism.

The problem is resolved by setting

Code: [Select]

Firewall->Settings->Advanced->Enable syncookies = none
Edited: Version is OPNsense 23.1.8-amd64

4

23.1 Production Series / Security issue with syncookie sequence numbers

« on: May 28, 2023, 02:46:27 pm »

When running OPNsense 23.1.8-amd64 with Firewall->Settings->Advanced->Enable syncookies = 'always' I have noticed that the reconstructed SYN sent by Opnsense to the remote destination always uses exactly the same tcp Sequence Number of 64240. I have verified this occurs with several well known destinations. I note that 64240 is the default tcp window size on my systems.

I believe that using exactly the same static sequence number in tcp SYN, is a security issue.

Here is an example of a Wireshark decoded initial SYN on my external WAN interface (syncookies enabled)

Code: [Select]

Internet Protocol Version 4, Src: <MY PUBLIC IP ADDRESS>, Dst: 157.240.252.60
Transmission Control Protocol, Src Port: 37615, Dst Port: 443, Seq: 0, Len: 0
    Source Port: 37615
    Destination Port: 443
    [Stream index: 0]
    [Conversation completeness: Incomplete, SYN_SENT (1)]
    [TCP Segment Len: 0]
    Sequence Number: 0    (relative sequence number)
    Sequence Number (raw): 64240
    [Next Sequence Number: 1    (relative sequence number)]
    Acknowledgment Number: 0
    Acknowledgment number (raw): 0
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x002 (SYN)
    Window: 0
    [Calculated window size: 0]
    Checksum: 0x8392 [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    [Timestamps]
        [Time since first frame in this TCP stream: 0.000000000 seconds]
        [Time since previous frame in this TCP stream: 0.000000000 seconds]

I would guess that this is a known issue but I am unable to find a reference to it.

 

5

23.1 Production Series / Re: ddclient and ClouDNS

« on: May 10, 2023, 05:05:28 pm »

Thanks for the suggestion.  Your workaround would work fne but running only once a day means that I might have to wait upto 24 hours before cloudns updates my DNS record.

I currently use the legacy "Dynamic DNS" plugin.  When that is finally removed from OpnSense (this summer?), unless the bug is fixed in the meantime, I would implement a workaround which monitors my external WAN ip address and whenever a change is detected would invoke the ClouDNS supplied script.  The workaround would involve using Monit service since I already a service which does something very similar. This way I would have a granularity of the order of minutes and I would not overload ClouDNS with requests when the ip address does not change.

I have opened a ticket on Github for the plugin here: https://github.com/opnsense/plugins/issues/3430

6

23.1 Production Series / Re: How to verify vlans working (like packets are actually tagged correctly)

« on: May 08, 2023, 06:31:40 pm »

Probably the easiest way is to use the packet capture function (Interfaces->Diagnostics->PacketCapture).

You need to capture the hardware interface which underlies your vlan. For example, I use a vlan with id 400 and here are the two interfaces of interest on my system:

• igb3                 This is the underlying hardware interface
• igb3_vlan400  This is the vlan.

In the example I would select as the capture interface igb3.

Do not select the vlan interface interface itself (igb3_vlan400 in the example).

When you have finished capturing the traffic, download the captured pcap file and view using Wireshark.

Hope that helps.

7

23.1 Production Series / ddclient and ClouDNS

« on: May 05, 2023, 03:30:20 pm »

I see that ClouDNS is now supported by Opnsense Dynamic DNS (ddclient).  However, having selected ClouDNS in the 'Service' field drop down list, it is not clear where my ClouDNS apikey needs to be put.

As an experiment I tried using various combinations of the following fields:
Username
Password
resourceid (using advanced mode)
Hostname= mydomain.eu

In each case the log showed an error similar to:
WARNING: skipping host: mydomain.eu: 'dynurl=' is an invalid string.

It seems as if the Opnsense GUI does not allow the ddclient data item 'dynurl' to be set. Is this a bug on the Opnsense GUI?

I should note that similar comments have recently been put on the  22.7 Legacy forum.

Opnsense version=OPNsense 23.1.7_2-amd64

8

22.7 Legacy Series / Re: Same rule for outbound traffic on WAN and LAN - logs action only on WAN intfc

« on: November 01, 2022, 07:53:46 am »

From your picture it seems that the rule on the lan interface (UIGLAN)  is set to fire only for outgoing traffic.

I think that you need it to fire for traffic tthat is incoming on the UIGLAN interface.

9

22.7 Legacy Series / Re: Using manually specified DNS servers for specific devices - Unbound DNS

« on: November 01, 2022, 07:46:48 am »

I have the same requirement.  For many years I have been using a NAT rule that is almost identical to yours.

The difference is that I have:
(Destination) Address: *

My rule ensures that any device in  ALIAS_HOSTS_DNS_REDIR which uses the DHCP provided DNS servers will also be affected.

Your rule will not fire if a device in  ALIAS_HOSTS_DNS_REDIR is using the DNS server on OpnSense (Unbound in your case).

10

22.1 Legacy Series / Re: os-ddclient

« on: August 25, 2022, 03:22:26 pm »

I am using a fully updated (on 2022-08-25) OPNSense version 22.7.2 commit  412c0b79c.

I use clouddns and I do not see how I can configure os-ddclient for this.

With the old client I use a Service type of Custom and provide an update URL similar to https://ipv4.cloudns.net/api/dynamicURL/?q=MYAPIKEY

I see that an issue regarding this has been opened at https://github.com/opnsense/plugins/issues/2880

Does anyone know of a workaround?  Or must I wait until issue 2880 is resolved?

UPDATE: 2022-09-02 Alas I see that issue 2880 has been automatically closed by the bot.  Does this mean that CloudDNS will never be supported by the OPNSense port of ddclient?

11

22.1 Legacy Series / Re: LAN traffic being randomly blocked by "Default deny rule", can't figure out why!

« on: April 14, 2022, 12:42:57 pm »

The blocked packet that you provide seems to be a tcp ACK being sent from your Source Device (SD), 192.168.1.20, to your Destination Device (DD), 10.0.1.11. Unfortunately MAC addresses are not given in the logs.

My understanding of your configuration is that for busy tcp connections initiated by SD, then all packets pass through the OPNSense Router (RO) whilst for busy tcp connections initiated by DD packets do not pass through RO (this because 192.168.1.11 is on the same network as 192,168.1.20). On its own this asymmetry is probably not a good thing and will almost certainly cause problems.

I believe the scope for problems is further compounded by the presence of the left hand green switch.  Promiscuous mode on the OPNSsense together with REJECT (instead of BLOCK) rules would not help either.

Given that you say the problem hits intermittently after a few minutes of a working connection, my first thought, given your configuration, is that the problem might involve one (or all of):

• left green switch mac-port cache table entry being timed out. Switches maintain a cache of mac-port pairs which time out typically after a minute or so.  The important point being that when an ethernet packet arrives at a switch for an  destination not in its cache, the switch sends the packet out to to ALL ports.
• pfSense router ip neigh cache entry is timing out. This cache hold ip-mac entries. When the ip stack receives a request to transmit to an ip that is not in its cache, it will do an ARP request either for the MAC of the destination, if on the same network, or for its configured gateway otherwise.
• if OPNSense has the lan interface (em1) in promiscuos mode, then packets would be sent up the ip stack even if the destination mac was not that of the OPNSense router. Possibly the blocked ACK was infact in an ethernet packet sent to the MAC address of SD but because of the switch cache timeout, the same packet also got sent to OPNSsense which then rejected the message tearing down your connection

The precise details of how your problem is provoked would depend on the dynamics of who sends what and when.

If you really wanted to understand then you could use wireshark and monitor macs and ip addresses of the various messages on the various links.

In any case I would suggest that you change your network configuration. 

If you cannot change the network config then, depending on the details of your config, it might be worth trying the following possible dirty workaround:
* changing the LAN default firewall rule in question to be BLOCK instead of REJECT (in the OPNsense logs on my system they are both marked as "block') as this would prevent the OPNSence from sending an icmp reject to DD. With a bit of luck everything else might continue to work as it did before you swapped in the OPNsense.

Hope that helps.

12

22.1 Legacy Series / Re: Security impact when enabling promiscuous mode

« on: March 15, 2022, 06:05:32 pm »

Ah, that's nice to know 

Thanks!

13

Intrusion Detection and Prevention / Re: Recommendation wanted: test event

« on: March 13, 2022, 08:10:55 pm »

Indeed you are correct!

Using that direct link, does download using http and so triggers the test suricata block.

Many thanks!

14

22.1 Legacy Series / Re: Security impact when enabling promiscuous mode

« on: March 12, 2022, 05:55:22 pm »

... once VLAN is used in your network: promiscuous mode is enabled.

This sounds as if it answers the question I posed in another thread;

My question is: why does IPS mode with vlans work without using Promiscuos mode on 22.1 and 21.7?

but I in that case I found that

root@OHM:~ # ifconfig | grep -i prom
pflog0: flags=20100<PROMISC,PPROMISC> metric 0 mtu 33160

that is, no interface had promiscuous mode.

Is ifconfig lying?   What is going on?

15

22.1 Legacy Series / Re: Security impact when enabling promiscuous mode

« on: March 09, 2022, 12:38:17 pm »

When you enable promiscuous mode on an interface, packets not addressed to that interface will be passed up the network stack instead of being dropped.

This means that your routing and firewall rules (and other services)  will encounter ip address (and protocols) that they might not be expecting, that could have security implications.