Messages

31

21.1 Legacy Series / Re: Can I challenge let's encrypt with opnsense natted?

« on: March 07, 2021, 02:46:31 pm »

Simplest solution is just to change DNS provider.

Who's your DNS provider currently?

I recommend you use Cloud Flare, their pretty good, plus you can use them as a CDN/Proxy and protect the origin easier from DDOS, plus other features There is a free tier, works fine and I've used it for years.

Edit: Just tested DNS challenge with Cloudflare, worked a treat, no messing with port forwarding and works behide NAT'd network. Cause my lab opnsense is NAT'd behind my main opnsense.

32

21.1 Legacy Series / Re: Can I challenge let's encrypt with opnsense natted?

« on: March 07, 2021, 01:44:37 am »

Are you actually going to be hosting any services at home?

Could you not create a internal CA on OPNsense, install it to your device and then create a Certificate for OPNsense for this?

33

21.1 Legacy Series / Re: Firewall Can Ping Google DNS, VM behind Firewall cannot, all rules allowed..

« on: March 07, 2021, 12:01:45 am »

Remoted on to Tryllz setup and he'd had it all setup correctly, between the two firewalls, and the gateway is required for the static routes, something I forgot  .

The reason to why the internet didn't work was due to Outbound NAT. Since FirewallA doesn't see any external networks of FirewallB, so when you use Automatic NAT, it doesn't create rules for these networks.

So I put his NAT in to manual mode and created 2 NAT rules which will cover 10.0.0.0/8 and 192.168.0.0/16, so when he creates any new external private networks be hide FirewallB, they'll get internet access if the firewall lets them.

I would of created a ALIAS called RFC1918 and then used that as the source on the NAT rule, but since the browser was being glitchy and wouldn't open then new alias model, I had to do it this way.

This issue should now be resolved as Tryllz can now reach the internet on the VM he couldn't do before.

34

21.1 Legacy Series / Re: Firewall Can Ping Google DNS, VM behind Firewall cannot, all rules allowed..

« on: March 06, 2021, 11:17:11 pm »

I'm still confused to why you have a second gateway its not required, for this setup.

Do you have Teamviewer or something I can remote in and take a look, as that would be easier? 

You can find me on the IRC room.

35

21.1 Legacy Series / Re: Firewall Can Ping Google DNS, VM behind Firewall cannot, all rules allowed..

« on: March 06, 2021, 09:55:49 pm »

I'm not sure why you configured it as a 2nd gateway on FirewallA, you should be using just static routes "System: Routes: Configuration".

What you should have is a static route to 10.0.64.0/27 to via the FirewallB address on the 192.168.28.0 network. If you start to use gateways you'll complicate things and may hit issues with reply-to.

Once the static route on FirewallA is done, it'll know how to return taffic for a 10.0.64.0/27 VM, which it'll route to 192.168.28.0/27 address of FirewallB. So it can then forward the traffic back to teh VM on the otherside.

I hope this makes more sense?

36

21.1 Legacy Series / Re: Firewall Can Ping Google DNS, VM behind Firewall cannot, all rules allowed..

« on: March 06, 2021, 02:22:39 am »

Does Firewall 1 know to route 10.0.64.0/27 via Firewall2 192.168.28.0 address.

So it knows where to send the return traffic to?

37

21.1 Legacy Series / Re: Firewall Can Ping Google DNS, VM behind Firewall cannot, all rules allowed..

« on: March 05, 2021, 10:39:23 pm »

Is VM behide Firewall 2 Traffic NAT'd when its goes to Firewall 1?

38

21.1 Legacy Series / Re: WireGuard Issue

« on: March 05, 2021, 11:34:18 am »

With the same advice as to how to get this working . I don’t see what beef there is with the “mods” given I don’t see anyone saying this setup doesn’t work because of FreeBSD - because it does work

Yeah I'm not sure what this "beef" is 🤔, have i missed something here?

39

21.1 Legacy Series / Re: WireGuard Issue

« on: March 04, 2021, 11:23:51 pm »

I gave up on it and installed pfsense. It just so happened the same week pf implemented WireGuard into the kernel. I've had no issues with it so far. The people here are very good about helping others however the mods just blame everything on FreeBSD. So anyway, not looking back. Good luck everyone.

Hehe, maybe you'll come back one day, and we'll be here waiting :-)

40

21.1 Legacy Series / Re: Frequency of git based config backups?

« on: February 25, 2021, 06:57:43 pm »

I've created a PR to add the information about the default 01:00 backup time (git push).

https://github.com/opnsense/docs/pull/316

41

21.1 Legacy Series / Re: Frequency of git based config backups?

« on: February 25, 2021, 12:55:05 am »

Yeah good note to add to the docs.

If you look at the logs on your OPNsense without any extra crons added, you will notice the remote backup happens at 1am, atleast in my timezone, I would guess its the same for all.

Code: [Select]

2021-02-24T01:00:00 configd.py[4643] [2cadc370-55c0-4654-b009-8a0b2474e66b] Performing remote backup
If you can confirm its the case for other timezones, add it to the doc :-)

My time zone is Europe/London.

Edit
Quick look in the code and this line sets the Cron for the backup, but little unsure on syntax but I'm guessing it means 0 minute and 1st hour. Which lines up with my log time. I'm on my phone otherwise I would confirm the values of that array.

Code: [Select]

$jobs[]['autocron'] = array('configctl system remote backup', 0, 1);https://github.com/opnsense/core/blob/51489f83de93840f2771fd65938658cd25f5a01c/src/etc/inc/plugins.inc.d/core.inc#L199

42

21.1 Legacy Series / Re: WireGaurd Public IP traffic replying out of wrong WAN.

« on: February 24, 2021, 10:11:25 pm »

Great to hear that it works! Makes sense. No upstream gateway, no reply-to. A different solution (without configuring the wg interface statically) would probably require code changes.

Me too  , good learning curve if anything.

Yeah I wonder if we need a dynamic upstream gateway option to go with the "Dynamic gateway policy", but I guess that's up to the dev's.

43

21.1 Legacy Series / Re: WireGaurd Public IP traffic replying out of wrong WAN.

« on: February 24, 2021, 08:20:38 pm »

I've gotten it working 

In the interface setting for the WG0. Instead of having it set as none like you do normally for WireGuard.
Setting the IPv4 Address and the correct IPv4 upstream gateway, boom it started working.

Rules now the reply-to
```
pass in log quick on wg1 reply-to (wg1 51.51.51.254) inet proto tcp from any to 192.168.1.20 port = rdp flags S/SA keep state label "b13b654e93dd92492f867ba7d182bce8"
pass in log quick on wg1 reply-to (wg1 51.51.51.254) inet proto icmp all keep state label "0e99bf94860f81e34a3b417ce79f8d77"
```

Is this how I should be doing it with WireGaurd, because of it also wanting to set the interface address when the wireguard-go service starts. Could this cause issues long term?

I did try ticking "Dynamic gateway policy" and setting "IPv4 Configuration Type" to none, but this doesn't look to generate the reply-to rules required.

44

21.1 Legacy Series / NPTv6 only working one way

« on: February 22, 2021, 08:25:40 pm »

Hi Guys,

Anyone seen or got this issue, I believe its started since OPNsense 21.1 NPTv6 is only working in one direction.

I can ping6 and connect to IPv6 resources on a VM to the internet.
If I connect from the internet to the VM on the NPT address, traffic doesn't return.

Now I can see in the firewall logs traffic coming in and replying on the VM and then back out the WAN again, but the source IP for the traffic leaving the WAN is "fd37:c611:72fb:80::10", should this of been translated too "2001:41d0:800:aa:aa:aa:aa:aa" because it is "2001:41d0:800:aa:aa:aa:aa:aa" when the ping originates from the VM not the external host.

VM IP: fd37:c611:72fb:80::10/64
NPT Rule:    2001:41d0:800:aa:aa:aa:aa:aa/128 -> fd37:c611:72fb:80::10/128
WAN IP: 2001:41d0:800:aa::1/64
 




Is this a bug?

Jonny

45

Tutorials and FAQs / Re: TUTORIAL: Set up WireGuard for limited local hosts to use external VPN provider

« on: February 20, 2021, 02:31:03 am »

So I have now updated the firewall section. I have left the outbound NAT section as is - although on its face it has a broader operation than the firewall rule, I figured that if the firewall rule is not sending local traffic through the WG gateway then the outbound NAT rule for the WG interface won't impact it. Let me know if you disagree. Thanks again for the input

Looks good 😊