Messages

1

General Discussion / Re: Maltrail, requests being forwarded to gateway

« on: January 30, 2022, 08:56:50 pm »

ok but why?

I can hit the management UI but not the maltrail GUI?

That doesn't make any sense unless it is somehow "special".

2

General Discussion / Re: Maltrail, requests being forwarded to gateway

« on: January 25, 2022, 01:58:21 pm »

I added another interface separately addressed to the firewall, added a rule to allow access and now it works.  I wonder if the listen interface on the webui has something to do with it but I'm not sure

Short answer for anyone who finds this: Run it on a different interface + address to the one acting as your gateway.

3

General Discussion / Re: Maltrail, requests being forwarded to gateway

« on: January 22, 2022, 11:56:19 pm »

So why can I reach the opnsense gui and not the maltrail one? I get the sending on but surely that should be consistent. Or do I misunderstand?

4

General Discussion / Re: Maltrail, requests being forwarded to gateway

« on: January 22, 2022, 03:29:36 pm »

Hey,

so 212.xxx is a gateway defined as a single gateway (External1) where the opnsense is the DHCP client of a bridge and External 2 has another upstream hop on another VLAN.

Another data point for you though, I access the opnsense GUI on the same address on port 443.  Is the GUI "special"?

i.e. 192.168.1.1:443 (Opnsense GUI), 192.168.1.1:5000 shipped upstream. 

192.168.1.1 *is* the default gateway for the network I'm reaching it from.

Cheers,
MB

5

General Discussion / Maltrail, requests being forwarded to gateway

« on: January 22, 2022, 08:26:23 am »

Hi,

I've installed maltrail and it seems to be up.  If I ssh onto the firewall and telnet to the port locally and do a get it works. 

All the requests from a remote machine on the network seem to be being forwarded to the gateway though, I see the firewall rules getting triggered (and passing).

Listening on all addresses:
 tcp4       0      0 *.5000                 *.*                    LISTEN


Local access:
Loopback      Jan 22 07:09:51   127.0.0.1:53854   127.0.0.1:5000   tcp   pass loopback   
Loopback      Jan 22 07:09:51   127.0.0.1:53854   127.0.0.1:5000   tcp   let out anything from firewall host itself   

Remote access:
   External1      Jan 22 07:24:12   212.xxx.xxx.xxx:49321   192.168.1.1:5000   tcp   let out anything from firewall host itself (force gw)   
lan      Jan 22 07:24:12   192.168.1.101:27996   192.168.1.1:5000   tcp   Inside outbound   
External2      Jan 22 07:24:11   192.168.9.31:58083   192.168.1.1:5000   tcp   let out anything from firewall host itself (force gw)   
External1      Jan 22 07:24:11   212.xxx.xxx.xxx 168.1.1:5000   tcp   Inside outbound


I did create a specific allow rule for the server but I don't think that's the problem.

Cheers,
MMB

6

General Discussion / Re: OpenVPN-AS: Advanced options

« on: January 22, 2022, 08:14:29 am »

Well I dunno, I mean presumably the reason for using the VPN in the common case is to get to the network on the inside.

7

General Discussion / Re: OpenVPN-AS: Advanced options

« on: January 21, 2022, 05:55:29 pm »

ahhh, ok, the road warrior VPN setup configuration should reference this as my following the guide is probably pretty typical.

8

General Discussion / Re: OpenVPN-AS: Advanced options

« on: January 21, 2022, 08:33:14 am »

Hey,

I don't know why they don't but: https://forum.opnsense.org/index.php?topic=26447.0

Explains what I've observed.

Plan today is to redo my tests and check the client route tables.

Cheers,
MMB

9

Virtual private networks / OpenVPN requires local push "route" to work - is "IPv4 Local Network" broken?

« on: January 20, 2022, 10:48:43 pm »

Howdy

I have configured OpenVPN, over TCP on the default port on my Opnsense firewall.  The problem was unable to reach the LAN. I have got it working. The question is, how and more importantly, why?

Configuration: Dual WAN LB
Connect to: Dynamic DNS hostname hanging off the combined UPLINK gateway
OpenVPN: TOTP + Internal CA
VPN Net: 10.10.0.0/24
LAN of interest: 192.168.1.0/24

I use the OpenVPN client to connect and it works, I get a 10.10.0.x ip address on my client computer.  If I try and hit 192.168.80 (some server) it doesn't work.

I check the firewall rules, IN on the openvps interface (annoyingly not a "proper" interface), and OUT on the LAN interface.  Green all the way (pass). Nothing.

Assumptions:
1) Client is successfully connected and authenticated.
Evidence: Connection logs the openvpn client and a 10.10.10.8 IP, logs on the firewall show connections

2) Packets are making it to the firewall and not being blocked (at least by the firewall)
Evidence: Firewall logs show that two rules are being matched, those matches are showing as PASS

ncat a server to see if it's just packets not getting back, nothing, no connections reach the target (10.10.0.8->192.168.1.80).

Ping fails to work, as does telnet as does http.

I then stumble upon this: https://forum.opnsense.org/index.php?topic=749.0 and another key entry asking when advanced options might be removed and what the alternative will be (I just can't find it despite looking for it now for far too long).

So I test the following advanced config:
push "route 192.168.1.0 255.255.255.0";

Lo and behold it works!

I can now, telnet to my ncat, I can http to random stuff, life is great. 

But WHY?  I hate not knowing why.  A bit of googling explains what push "route" is doing https://forums.openvpn.net/viewtopic.php?t=9055, save you clicking on the link:

route 10.0.1.0 255.255.255.0
is used to add to local OpenVPN server's routing table only. And it may be used as on OpenVPN server as on client too.

push "route 10.0 .2.0 255.255.255.0"
is used only in OpenVPN server's config to push the routes to client's. Insteed of using "route" command on all client's config, you can use one "push route" on server config to do the same on all clients.



With this in mind I then monkey with the option: REDIRECT GATEWAY expecting what this will do is just be a cheap and easy way to capture all the traffic and send it to the VPN.  I remove push route and this works exactly as expected, it works, stuff reaches my internal network over the tunnel.

This is all fantastic but it leaves me with two questions:

1) Why does this not work if I specify the IPv4 Local Network as : 192.168.1.0/24 (which I do)
2) Why does the traffic appear to hit the firewall, trigger some rules, pass them but not work, especially if the reason is there is no route?

This is

1) potentially a bug in how IPv4 Local Network is supposed to work and
2) TOTALLY BONKERS in that traffic reaches the firewall from the client!!

If you got this far, well done.
If you understand what I'm getting at.

Cheers,
MMB

p.s. all this after figuring out that TOTP authenticator bug with a mismatch between server config for timing and the client config (answer, just leave the defaults)

10

General Discussion / Re: OpenVPN-AS: Advanced options

« on: January 20, 2022, 09:10:17 pm »

Just giving this topic a nudge,

I have exactly the same issue, it looks like the IP V/4 local network box doesn't do what you want it to

11

20.1 Legacy Series / Firmware status check was aborted internally. Please try again.

« on: June 20, 2020, 11:22:40 pm »

Hi,

Just an answer for a question in case you have the same problem I did. 

The kicker here is I have two gateways in a gateway group and one is down.

First error is the one above, firmware aborted.

Looking in System->Log files->Backend->

You see something like:
2020-06-20T21:08:48   configd.py: [a9b24ab8-c6e8-4258-8b39-fa198867b290] Show log
2020-06-20T21:04:08   configd.py: [06155d67-9587-4fcc-b545-096a7eefee37] retrieve upgrade progress status
2020-06-20T21:04:08   configd.py: [5b4c5b9a-1da4-455e-ace9-311c6d523094] Retrieving changelog index
2020-06-20T21:04:08   configd.py: [66aff237-681b-4f0a-91bf-b034e7335d62] view local packages
2020-06-20T21:04:08   configd.py: [b862b845-ad7b-4ded-893c-ceec4c3ab3f6] Script action failed with Command 'pkg rquery "%n|||%v|||%c|||%sh|||0|||%L|||%R|||%o"' returned non-zero exit status 74. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/processhandler.py", line 484, in execute stdout=output_stream, stderr=error_stream) File "/usr/local/lib/python3.7/subprocess.py", line 363, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command 'pkg rquery "%n|||%v|||%c|||%sh|||0|||%L|||%R|||%o"' returned non-zero exit status 74.

If you shell onto the box to try to see if you can run this interactively, and do some more googling you might stumble upon some people remarking that the package server pkg.opnsense.org is down (I didn't believe this) so you try to ping it.   

Then you discover it is down.  So you go huh.  Then you try to ping some other things. 

root@firewall:/home/<dude># ping www.google.com
PING www.google.com (216.58.204.36): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down

Now that *is odd*.  But your firewall is working?! And if you ping from diagnostics you get stuff fine and you can nslookup and so on.  People are accessing the internet through it and everything.

You do some more digging and you get "no route to host".  This is funny because clearly it does and the firewall can route stuff from itself out.

Then you run:
root@firewall:/home/<dude># route get www.google.com
   route to: ber01s14-in-f4.1e100.net
destination: default
       mask: default
    gateway: 192.168.50.1
        fib: 0
  interface: inf0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

At which point you now immediately know what's wrong.  Because 192.168.50.1 is gateway 1 of 2 and it is *offline* but not down.

I would attach a screenshot but the point is that both interfaces are shown as up although one is *offline*.  If you disable the interface that is offline and bring it down specifically, then the other one gets promoted to be the relevant route and voila.

It all starts to work.  Obvious really.

Therefore:

If you have *failing package updates*, with two gateways, 1 is offline but the interface is not down, bring it down properly for the purposes of your updates.  Then bring it up again so that it'll all work once it comes online again.

Hope this helps,

Cheers,
MB

12

19.7 Legacy Series / Re: Feature Request: API - Firewall - alias_util - Add

« on: June 07, 2020, 04:25:41 pm »

Hi there,

Can you share a snippet of code where you have this working because I get, variably:
{"status":"failed","status_msg":"non existing alias <aliasname>"}

for a post to /api/firewall/alias_util/add/test

For what it's worth I have also tried addItem but that also fails.

Cheers,
MB

13

General Discussion / Re: Unbound not returning results

« on: June 06, 2020, 12:58:37 pm »

Hi marjohn,

So I bottomed it out in the end.  I went through a number of steps, enabled it, checked to see if it was bound to the right IP addresses (via process/netstat), tested it via interfaces->diagnostics and tried to query from the firewall itself for things both outside and things that were only in the overrides.  Anything from off the box did not resolve and didn't put anything in the unbound log.

Long story short it was some issue with the firewall and I suspect something quirky with "quick match", which I am yet to fully wrap my head around for *allow* rules.  Oddly enough you could see the query match the port and be allowed inbound, you'd get a "pass" in the firewall rule from the client on port 53 to the ip+port that unbound was definitely bound to on the firewall itself.

If I had to guess, I think some other "quick match" rules behaviour meant that it was hitting one rule (Pass) and then somehow hitting another which wasn't logging and then some kind of priority problem ensued and the firewall silently dropped the packet.

When I binned off all my rules and started a fresh and got rid of quick match as a concept it started to work.

Thanks for replying though 

14

General Discussion / Re: Unbound not returning results

« on: June 01, 2020, 09:32:32 am »

I should probably have made it clearer, I don't see *anything* related to the apparent activity in the unbound logs.

15

General Discussion / Unbound not returning results

« on: May 31, 2020, 06:25:57 pm »

Hi All,

I am new to Opnsense.  I'm trying to replace an existing firewall with opnsense.  I've configured it and it appears to be working well enough, multi-wan load balancing and I have some very basic rules and I can indeed reach the internet if I reconfigure end points default gateways.  It also seems to be dealing with my VLANs.

I have configured :

System: general: DNS Servers to point at OpenDNS.  If I do interface:Diagnostics I can get addresses to resolve on the internet. I have enabled and disabled "Do not use the local DNS service as a nameserver for this system" to no avail.

Unbound DNS: configured on port 53 and logging cranked up to 11 (ok 5).  Forwarding enabled and configured query logging. 

Firewall rules: have enabled access from the LAN to port 53 on the the firewall. In the firewall logs I can see the requests coming on port 53 *AND* what's interesting is I also see outbound traffic on port 53 (like the forwarding is attempting to go out).  EVerything is passing the pass rules with no drops


Problem is I get timeouts from NSLOOKUP.  I also get nothing in the logs (in the UI) for Unbound.

I also added local overrides in Unbound and tried to look those up also didn't work.  I read something about abug in overrides so I then removed them all as a test, still no joy.

What else can I check?  What else am I missing?

Cheers
MB