Messages

1

20.7 Legacy Series / Re: Running as a test system in VM, can't access hosts on LAN?

« on: December 29, 2020, 07:06:45 pm »

(More...)

2

20.7 Legacy Series / Re: Running as a test system in VM, can't access hosts on LAN?

« on: December 29, 2020, 05:36:33 pm »

Yes - and there can't be a question about connectivity at a network level.  See attached.  I'm getting DCHP requests and responses at my main router, and ARP requests and responses picked up at my fileserver, as well as responsiveness from my browser to the Web UI on the host PC.


More than that, "tcpdump -i em0 -vv" on the OPNSeense console shows it's seeing the arp replies ("arp is-at" from other LAN devices,  but when I type arp -a, they aren't in that list, it asks again.

The IPs mentioned - 10.5.100.85 is the arbitrary IP offered by DHCP, that isn't working because it's not received, and 10.22.46.5 is the static IP I set on WAN in the Web UI, that is working to the extent mentioned.

arp -a and ifconfig confirm that the ARP replies and DHCP replies arent being received by the OPNSense router. And yet, firewall log is empty, RFC1918 is unchecked, and inbound "pass all" rules are set and activated on the WAN.


(More screenshots in next post)

3

20.7 Legacy Series / Re: Running as a test system in VM, can't access hosts on LAN?

« on: December 29, 2020, 12:09:14 pm »

Interfaces, WAN interface, untick 'block private networks'

OPNsense disallows RFC 1918 address ranges on its public interface by default.

It's already unblocked, though I forgot to say so. Just rechecked, and added a mention to OP for clarity.
It's not that..... hence my confusion. What else could it be?

4

20.7 Legacy Series / Running as a test system in VM, can't access hosts on LAN?

« on: December 28, 2020, 06:50:04 pm »

I'm running a slightly unusual situation that *should* be easy,and I've installed OPNSense dozens of times, but I'm failing every time on this, and I've run out of ideas what I'm missing.


I want to test some dev things on OPNSense - doesnt really matter what. So I don't need it operational, I just need a bare install with internet and LAN access.  My LAN is IPv4 with a flat desktop switch using 10.0.0.0/9, so I installed using VMWare Workstation and the OPNSense install ISO (set at FreeBSD 12 x64 guest).


After first reboot I set WAN = em0/DHCP and no LAN (which according to the console menu would trigger full firewalling mode). It assigned 0.0.0.0. Fail. DHCP works on every other LAN device, but this wasn't picking up an IP. I checked with TCPDUMP on the main ("real") router and in its logs, I can see ARP who-has and replies, and DHCP discovery/offer as expected. But the VM OPNSense wasn't picking them up.


This isn't to do with name resolution, as it gets "host unreachable/down" even on IP pings.


So I set WAN as a static 10.x.x.x/9 IP, which let me into the Web UI from my desktop. I used the Web UI to create manual rules to pass all IPv4inward (and for avoidance of doubt, outbound) on WAN, then within the web UI, I set WAN to DHCP and disabled RFC1918 blocking (thanks Bart, forgot to mention this first time, just rechecked and it was unchecked) - and it still wasn't able to pick up an IP.

• It's definitely got access from the LAN, so networking is fine - I can reach the web UI.
• I can see DHCPDISCOVER/DHCPOFFER in my main router's DHCP log, and ARP who-has and replies via tcpdump on the LAN
• RFC1918 is unchecked on WAN
• The vm install can't ping anything, including the main router/DHCP server, even though other LAN devices can, and the ARP replies seen via tcpduymp aren't showing in its arp cache (arp -a)

What could be going on?


More generally, whats the simplest way to run OPNSense in a vm and have it able to communicate to the internet?


If needed, the config has no sensitive data and I can attach it. But I'm hoping there is an obvious answer Im missing.

5

Documentation and Translation / Permissions on certificate bundles

« on: August 26, 2020, 02:04:45 am »

The docs just state to set "some sane permissions" on certificate bundles for the internal web server.  Hardly specific.


What permissions are minimally recommended for the internal web server?


Would similar permissions be appropriate for other certs like SSH?


Thanks for answers, and if someone could update the docs with that info it could help others too

6

Development and Code Review / Re: What is this snippet's effect, in the volt template?

« on: November 12, 2019, 04:14:50 pm »

PR submitted:  https://github.com/opnsense/core/pull/3814

7

Development and Code Review / Re: What is this snippet's effect, in the volt template?

« on: November 12, 2019, 12:32:57 pm »

Originally it came from https://github.com/opnsense/core/commit/4c736c65060c926ecc9eb7539b93454559e9d2d4 intended to display "wide" forms, see "Administration -> Intrusion detection -> Rule" for its usage.

It's not at the top of my priority list, but I wouldn't mind removing the parameter if both form types still look decent. As far as I see, we only use it in IDS at the moment, so it should be easy to refactor and test.

Excellence of replying!
   
The 3 column dialog definition (whether 3:4:5 or 3:8:1) is used everywhere, so I'm hesitant to totally remove it and go back to 2 columns (3-9), because of the number of affected forms that would needed <td></td> or similar removed, and colspans updated.   

However, changing the split from 3:{9-msgzone_width}:{msgzone_width} to a static 3:9:0 or a default of msgzone_width=0 with a comment explanation in the 2 volt base files, works just as well. Looks good,no bugs or glitches. Help text stretches, message boxes stay sensible widths. All nice. Also easier reversible. Tested on IDS rules dialog, as well as on dialogs with long wrapping help texts. Does that work for you? Would need minor css edit for col-md-0, to check it doesn't create a zero width box but an extra 2 margins worth of white space, but that's trivial. What do you think? Also why is this just col-md, and not other sizes? Does it need to be?

Allso self-note, if it changes or goes, the hard-coded defaults in base_form.volt also would need to change too.

8

Development and Code Review / What is this snippet's effect, in the volt template?

« on: November 12, 2019, 02:31:13 am »

In layout_partials/base_dialog.volt, at lines 71-73 and again 104-106, there's a snippet I don't fully understand the implications/intent of. So I'm not sure how best to approach its issues either:
 

Code: [Select]

<table class="table table-striped table-condensed">
    <colgroup>
        <col class="col-md-3"/>
        <col class="col-md-{{ 12-3-msgzone_width|default(5) }}"/>
        <col class="col-md-{{ msgzone_width|default(5) }}"/>
    </colgroup>...  
The function and part of the intent is clear. At the top of the generated form HTML, it divides the standard bootstrap 12 cols into 3 "blocks" comprising { (3)  + (9-msgzone_width) + (msgzone_width) } bootstrap columns respectively. The default of 5 matches the 3-4-5 default values hard coded into base_form.volt. The param is rarely used; clearly from usage and code inspection, the left "Block" is the label for controls, the "message zone" is the right hand column which seems unused, the form controls and their help text fit into the middle "block". That much is clear.
   
What this does however is, give the popup dialogs created from this template, a huge white space margin, and forces the help text to wrap much sooner than it needs to. Attached is a screenshot of how it renders for me. Huge white space, no centring, gets worse as the window size varies. Text wraps poorly making the form long.
 
I'm looking at this and wondering, can something be done to improve this, or is there a functional reason it's set that way? Of course the default can be altered for specific forms, but I'm wondering if it's actuisally got poor choices of zsizing and things. But I don't fully understand the use of the 3rd column and the overall implications and how it fits into OPNsense UI, or the function of col class=.... in this snippet, to know what to make of that. Is this axctually doing what it's intended to, and could it do it better?
 
Insights or suggestions how to work with this (or even minimally modify it), so that dialogs can use a little more of the dialog horizontal whitespace without unforeseen layout issues elsewhere, really appreciated!

9

Development and Code Review / Re: Implementing a better ICMP selector in filter rules

« on: November 11, 2019, 05:02:23 pm »

Great. Excited to test it.

I'm letting a current batch of underlying PRs get sorted out before I PR it.  Shouldnt be long with luck.  Meantime Im playing round with another project I've  wanted for a while - giving Monit the ability to send notifications via other common routes. Making quick progress, its proving pretty simple. Basically making it ready to accept new alert methods people might want, as right now its totally geared to email, rather than a choice of a few delivery methods. And adding at least 1 other method to show it works, however simple - whether IRC, telegram, slack, growl, GSM card via serial, whatever. A lot of ways people might use to get alerts these days, all come down to a very similar function:  URL + API key/login + appropriately formatted URL/HTTPS/POST/headers + cURL.  So making Monit able to choose between say email and some one other, for an alert, is more about enabling other devs to easily add delivery methods they want in future, if they need to, than about any one specific delivery method.

10

19.7 Legacy Series / Re: Unbound custom parameters

« on: November 10, 2019, 08:46:46 am »

I'm using the custom options for a few areas now:

 - To provide "split horizon" for different subnets, or for LAN vs. WAN (I could spin up two unbound instances but that's completely off the rails, and if Unbound is my resolver of choice I don't want to be forced to run 2 resolver softwares  just to get different views)
 - To provide static responses that aren't available in the GUI for certain domains, such as manual dns-sd entries, and <local-zone: "DOMAIN" static> entries.

My Unbound.conf code custom snippets:

Code: [Select]

log-queries: yes
log-replies: yes

qname-minimisation: yes


# dns-sd manual entries

local-data: "b._dns-sd._udp.MY-FQDN IN PTR MY-FQDN"
local-data: "db._dns-sd._udp.MY-FQDN IN PTR MY-FQDN"
local-data: "r._dns-sd._udp.MY-FQDN IN PTR MY-FQDN"
local-data: "dr._dns-sd._udp.MY-FQDN IN PTR MY-FQDN"
local-data: "lb._dns-sd._udp.MY-FQDN IN PTR MY-FQDN"
local-data: "b._dns-sd._udp.0.0.193.10.in-addr.arpa. IN PTR MY-FQDN"
local-data: "db._dns-sd._udp.0.0.193.10.in-addr.arpa. IN PTR MY-FQDN"
local-data: "r._dns-sd._udp.0.0.193.10.in-addr.arpa. IN PTR MY-FQDN"
local-data: "dr._dns-sd._udp.0.0.193.10.in-addr.arpa. IN PTR MY-FQDN"
local-data: "lb._dns-sd._udp.0.0.193.10.in-addr.arpa. IN PTR MY-FQDN"
# Device #1: various definitions for primary printer
local-data: "MY-PRINTER.MY-FQDN A IP-ADDRESS"
local-data: "_printer._tcp.MY-FQDN PTR _MY-PRINTER._printer._tcp.MY-FQDN."
local-data: "_MY-PRINTER._printer._tcp.MY-FQDN SRV 0 0 631 MY-PRINTER.MY-FQDN."
local-data: "_printer._tcp.MY-FQDN PTR _MY-PRINTER._universal._sub._ipp._tcp.MY-FQDN."
local-data: "_universal._sub._ipp._tcp.MY-FQDN PTR _MY-PRINTER._universal._sub._ipp._tcp.MY-FQDN."
local-data: "_MY-PRINTER._universal._sub._ipp._tcp.MY-FQDN SRV 0 0 631 MY-PRINTER.MY-FQDN."
local-data: "_MY-PRINTER._universal._sub._ipp._tcp.MY-FQDN TXT txtvers=1 qtotal=1 adminurl=https://MY-PRINTER.MY-FQDN ty=MY-PRINTER note=(LOCATION) usb_MFG=HP usb_MDL=MY-PRINTER Scan=T Duplex=T Color=T PaperCustom=T"
local-data: "_printer._tcp.MY-FQDN PTR _MY-PRINTER._pdl-datastream._tcp.MY-FQDN."
local-data: "_pdl-datastream._tcp.MY-FQDN PTR _MY-PRINTER._pdl-datastream._tcp.MY-FQDN."
local-data: "_MY-PRINTER._pdl-datastream._tcp.MY-FQDN SRV 0 0 9100 MY-PRINTER.MY-FQDN."
local-data: "_MY-PRINTER._pdl-datastream._tcp.MY-FQDN TXT txtvers=1 qtotal=1 adminurl=https://MY-PRINTER.MY-FQDN ty=MY-PRINTER note=(LOCATION) usb_MFG=HP usb_MDL=MY-PRINTER Scan=T Duplex=T Color=T PaperCustom=T"
local-data: "_printer._tcp.MY-FQDN PTR _MY-PRINTER._ipp._tcp.MY-FQDN."
local-data: "_ipp._tcp.MY-FQDN PTR _MY-PRINTER._ipp._tcp.MY-FQDN."
local-data: "_MY-PRINTER._ipp._tcp.MY-FQDN SRV 0 0 80 MY-PRINTER.MY-FQDN."
local-data: "_MY-PRINTER._ipp._tcp.MY-FQDN TXT txtvers=1 qtotal=1 adminurl=https://MY-PRINTER.MY-FQDN ty=MY-PRINTER note=(LOCATION) usb_MFG=HP usb_MDL=MY-PRINTER Scan=T Duplex=T Color=T PaperCustom=T"
local-data: "_printer._tcp.MY-FQDN PTR _MY-PRINTER._ipps._tcp.MY-FQDN."
local-data: "_ipps._tcp.MY-FQDN PTR _MY-PRINTER._ipps._tcp.MY-FQDN."
local-data: "_MY-PRINTER._ipps._tcp.MY-FQDN SRV 0 0 443 MY-PRINTER.MY-FQDN."
local-data: "_MY-PRINTER._ipps._tcp.MY-FQDN TXT txtvers=1 qtotal=1 adminurl=https://MY-PRINTER.MY-FQDN ty=MY-PRINTER note=(LOCATION) usb_MFG=HP usb_MDL=MY-PRINTER Scan=T Duplex=T Color=T PaperCustom=T"


# kill list
# for domains where redirect to 127.0.0.1 or other IP is insufficient

local-zone: "DOMAIN" static
local-zone: "DOMAIN" static
  # and many others


# split horizon #1

access-control-view:  10.0.0.0/8     FROM-LAN
access-control-view:  0.0.0.0/0      FROM-WAN
access-control:       0.0.0.0/0      deny_non_local

view:
      # from lan - can recurse to root servers, can also use global data if nothing found in this section.
      # so we actually don't have to put anything much here.
  name: "FROM-LAN"
  view-first: yes

view:
      # from wan - forbidden to recurse, and can't access the data in the global section, or anything not explicitly stated in this view.
      # so we only need to put here, what an external WAN query needs to be able to find.
  name: "FROM-WAN"
  view-first:no
  local-zone: "." refuse
  local-data: 'FQDN.  DNS_RECORD '
  local-data: 'FQDN.  DNS_RECORD '
  local-data: 'FQDN.  DNS_RECORD 'There's a big difference between not adding a feature, vs. removing one that's already in use. Maybe stuff like this could be retained with a tunable added "Enable unverifiable config fields", so those who are by now depending on it, dont' worry they'll lose it?

11

Development and Code Review / Re: Implementing a better ICMP selector in filter rules

« on: November 10, 2019, 08:12:31 am »

Done and working really smoothly and nice Not much code needed to do it, either.

Got about 3 PRs already waiting review, holding off on more just to avoid too much at once. Also some of them fix issues in the rules pages and I'll rebase if they're accepted.

12

Development and Code Review / Implementing a better ICMP selector in filter rules

« on: November 06, 2019, 03:16:59 pm »

I'd like to enhance the filter rules page to allow (1) multi-select of ICMP subtypes within a filter rule, and (2) where an ICMP subtype can validly apply to both IPv4 and IPv6, such as echo request/reply, to allow that subtype to be used in rules with protocol = "IPv4+IPv6".
 
The aim is to allow a router admin to avoid pointless and distracting multiplicity of rules whereby several ICMP subtypes must be given in many otherwise-identical rules just because they can't go in one rule, and then *all* of these rules must be repeated a *second* time for both v4 and v6 because ICMP filters can't currently be used within IPv4+IPv6 rules. 
 
I already wrote this code for pfSense a while back, before I moved to OPNSense, so I know it's easy, and the code works.  It's been part of that project for years. But I'm not yet familiar with the way mvc works in the codebase (despite reading the wiki) - sorry, the details within OPNSense is just extremely unfamiliar - so I'd like to check "what will go where" with a view to writing and testing an OPNSense PR for this enhancement.
 
The working code I'm starting with looks like this:

• firewall_rules_edit.php (protocols list): ICMP and ICMP6 are replaced by a single entry "ICMP v4+v6". This is similar to how we have IPv4+IPv6 in the protocol field. (The pf.conf generated by filter.inc still of course contains icmp and icmp6 as needed). There are 2 copies of these tables in the codebase so they can probably be replaced by a single copy in some appropriate file.
   
• firewall_rules_edit.php + firewall_rules_edit.php (tables of ICMP+ICMP6 subtypes):  ICMP subtypes tables for v4+v6 are merged into a single table, which lists all subtypes, with each flagged as "valid for v4? valid for v6?". These tables are only used very few times in the codebase, so consequential changes are trivial.
   
• firewall_rules_edit.php:
  - the merged ICMP subtypes table is used to build a table with 3 subarrays giving the valid data for IPv4, IPv6 and IPv4+6 rules respectively
   
  - if $proto == 'icmp', the validation code checks that the selected ICMP subtypes are all valid for the IPv* selected
   
  - a multi-select rather than dropdown field is used for ICMP subtypes. Its contents+selection are initially populated by Javascript. They are also updated by Javascript, if IPv4/6/46 is changed by the user, to ensure the ICMP subtypes displayed+selected remain compatible.
   
• firewall_rules.php: the "long format" rules table lists all ICMP subtypes selected, whethere one or multiple. The "short format" table just shows the number of subtypes against ICMP rules (e.g: "ICMP (4)" ) which can be hovered/expanded to view the specific list of subtypes.
   
• FilterRule.php (rule generation for rules with protocol=ICMP):
  - As a first step, builds a subtype-string giving the actionable subtypes in pf.conf format. If an ICMP rule contained just one subtype, then this string would look like "subtype". If the rule contained multiple subtypes, the string would look like "{ subtype, subtype, subtype, ...}".
   
  - ICMP and ICMP6 are then handled trivially as part of IPv4 and IPv6 handling. Meaning:  as the code stands, inet46 rules result in two pf rules being created, one for IPv4 and one for IPv6. So for ICMP rules, if the IP type is inet then an "icmp-type [subtype-string]" clause will be generated.  If the IP type is inet6 then an "icmp6-type [subtype-string]" clause will be generated. If the IP type is inet46 then an "icmp-type [subtype-string]" clause will be used in the resulting inet rule and an "icmp6-type [subtype-string]" clause will be used in the resulting inet6 rule.

This all seems pretty simple.  What I'm not clear about is this: 
 
The code I created is 100% PHP with some HTML+JS. I can find equivalent PHP in OPNSense and adapt the existing code to work properly.   That's trivial.  But some of the above, mainly related to the GUI, its fields, and their validation, I'm not at all clear what's required.
 
Can someone kind, please help me a bit, by running through the 8 code bullets above, and let me know which bullets are a matter of finding+editing the equivalent PHP in OPNSense and just need pure PHP code work to bring into OPNSense, and which bullets will require totally reimplementing in OPNSense because they work totally differently (XML/Phalcon/validation/mvc/HTML/JS/??).
 
(And the bigger picture is, I have a number of enhancements I've done, and I want to continbute PRs more actively.  But I feel stalled by this aspect.  Hopefully what I learn from this small port will mean I can PR other useful work I've done, without needing to ask as much.)

13

19.7 Legacy Series / How to fully reset Let's Encrypt ACME plugin for a specific certificate?

« on: November 05, 2019, 07:31:03 pm »

I've been testing the Let's Encrypt ACME plugin in the staging envioronment.

I want to force the plugin to revalidate the DNS ownership, but can't figure how to do it.
I've deleted the private key and revoked the existing certificate in the GUI, I've deleted all the files I dare from /var/etc/acme-client in Console, but whatever I have tried, when I click the GUI button to forcefully (re-)issue the selected certificate, the log contains this:
"<MYDOMAIN.COM> is already verified, skip dns-01"
How do I reset the client so I don't get this, and so it's forced to reverify DNS-01?


 

14

19.7 Legacy Series / Re: Tiny internet-facing service on OPNSense - run in jail, or something else?

« on: October 22, 2019, 12:47:02 pm »

Interesting topic. 11.0 is no longer available but apeears 11.2 is. OpenSSL old version. If I Remember Correctly, some ports won't build with that old version. SSHd includes insecure ciphers.
So, a number of things that could be or need to be fixed, but other than that, I think that recipe answers your question.
2. You give it an RFC1918 internal address and Destination NAT to that.

My main concern is, I'm using a security-aware OS, and a security-aware router software, by a security-aware team. I'd like to not accidentally expose anything by blindly following a recipe that I didn't realise had holes in it. 

I'm fairly confident that the service I want to run, is small and "narrow" enough I won't open holes by miscknfiguring its .conf files, and I don't need ssh or ftp either (host based jexec and file access are enough). But I'm wary of following a 2 year old recipe of comparatively unknown provenance for the jail.setup, without rechecking here with people who know the platform. Is the jail *really* in fact going to be well configured if I follow that recipe? Is it "safe" against external attack against its exposed services  (for a reasonable definition of "safe')?

Also, the dns service only needs very limited ports (53 basically), and outward onky access to the WAN (for updates/upgrades). So I figure I can use port mapping instead of NAT - give it a public IP's port 53 on the host, use OPNSense to map that to some other port on the jail's IP, and lock down all other incoming ports on the public or jail IPs on OPNSense. The only issue would be if the jailed system needs loopbsck I guess?   


Last, as OPNSense uses HardenedBSD as its platform, should I install that into the jail rather than usual FreeBSD? And if so does the version have to be identical? (Eg when OPNSense gets an upgrade)?

15

19.7 Legacy Series / Tiny internet-facing service on OPNSense - run in jail, or something else?

« on: October 20, 2019, 05:41:05 pm »

I'm planning to.install a small public-facing service on my OPNSense router (doesn't really matter the details, djbdns and a tiny static-file-only httpd, both pretty much serving static data files only, and a few queries a day). I want to run these on the router itself  because I don't need a second server or VM for such tiny things, and so I'm sure they are up and running any time the router itself is. Other threads on this forum make it look clear that adding jails should be completely workable and not in conflict with OPNSense core/plugins.     

I came across this short thread from 2017 which gives a very clear step by step "recipe" for the exact same goal. So most of my questions have been answered.  I have only 2 crucial questions left before going ahead:   

• Are the instructions from 2017 still appropriate in 2019? Has anything changed? Is there anything else I should do, to ensure security isn't compromised, or cut off non essential system capabilities from within the jail? Is a jail still the right way to go?
• How do I configure the jail IP to be behind the router's own pf firewall, for example to rate limit attackers/spam, or to limit any IPs/networks able to reach the jail?

Any tips on those 2 questions, or other useful info, much appreciated, so I go ahead safely!