Messages

1126

German - Deutsch / Re: Open VPN Problem

« on: November 26, 2019, 05:33:12 pm »

Mir wird immer weniger klar was Du vor hast... Deiner Beschreibung nach möchtest Du ein Site-to-Site-VPN (Standortvernetzung), konfiguriert ist aber Remote Access.

Hast Du dir mal die Tutorials im Wiki angeschaut?

Grüße

Maurice

1127

German - Deutsch / Re: RDP Verbindung über VPN herstellen

« on: November 26, 2019, 12:05:45 pm »

Was bezweckst Du mit dem NAT und Port-Forwarding? Die Server sind doch aus dem OPNsense-LAN unter ihrer VPN-IP-Adresse erreichbar? Wieso nicht einfach ein DNS-Eintrag pro Server? Also:
server1.example.com.   A   10.10.10.2
server2.example.com.   A   10.10.10.3
...

Grüße

Maurice

1128

German - Deutsch / Re: Open VPN Problem

« on: November 26, 2019, 11:43:09 am »

Deine Netze überlappen sich, da sind solche Probleme vorprogrammiert (192.168.5.0/24 liegt innerhalb von 192.168.0.0/20). Eines der häufigsten Probleme bei Standortvernetzung mit IPv4.

Wenn möglich: Netz(e) readressieren, so dass sie überlappungsfrei sind.
Ansonsten brauchst Du wilde Workarounds wie NAT oder statische Routen auf Endgeräten.

Grüße

Maurice

1129

19.7 Legacy Series / Re: OpenVPN: remote routes work from shell, not from LAN

« on: November 25, 2019, 10:05:49 pm »

A simple allow rule where you only specify the destination. The destination is the network(s) you want to exclude from being forcibly routed via the WAN gateway group. In your case: Networks which should be routed via VPN. You need to manually specify this (directly in the firewall rule or by creating an alias). If in doubt, have a look at your routing table.

Cheers

Maurice

1130

19.7 Legacy Series / Re: OpenVPN: remote routes work from shell, not from LAN

« on: November 25, 2019, 09:37:53 pm »

I do have dual WAN setup as described in the docs.

This means you use policy based routing, e. g. you have a firewall rule on the LAN interface which forces all packets coming from the LAN to your WAN gateway group. This overrides the routing table.

You need to add another, higher priority rule which allows packets going to your VPN network(s), but doesn't apply policy based routing to them.

Cheers

Maurice

1131

General Discussion / Re: New install, newbie question: 1 physical interface, shall it be LAN or WAN ?

« on: November 25, 2019, 03:37:08 pm »

First things first: Using OPNsense as your WAN-facing router would make things easier and potentially more reliable. So if you're planing for that anyway, you might want to skip ahead to that setup directly.

Running OpenVPN on OPNsense behind your primary router should work pretty much the same way as on your old Debian box: LAN interface only. You will also have to create a static route to your VPN prefix on either your Windows server (if this is the only machine that needs to be accessible by your VPN clients) or on your primary router. (Or you could set up a bridged (tap) VPN, but this is generally not recommended.)

Cheers

Maurice

1132

19.7 Legacy Series / Re: Guest Network on VLAN or OPT1?

« on: November 21, 2019, 10:03:01 pm »

From a layer 3+ perspective, it doesn't matter whether you use two physical ports or one with VLANs. If you have spare ports and the OPNsense box is close to your switch, using two cables isn't a bad idea. Higher throughput, no VLAN configuration in OPNsense required. If you have limited experience with VLANs this would also make testing and troubleshooting easier.

Whether you use separate APs or not isn't relevant for the OPNsense configuration. And no matter what, you will always have to configure VLANs on the switch.

Cheers

Maurice

1133

19.7 Legacy Series / Re: IPv6

« on: November 15, 2019, 03:21:39 pm »

With most ISPs, you have to request your prefix using DHCPv6, even if it is a "static" prefix. They won't route the prefix to you until you have completed DHCPv6 Prefix Delegation.

So even if you configure your LANs statically, use DHCPv6 on the WAN.

Cheers

Maurice

1134

19.7 Legacy Series / Re: external access web interface OPNsense over IPv6 on PPPOE

« on: November 15, 2019, 02:34:17 pm »

If you really can't get a WAN GUA using either SLAAC or DHCPv6, you can manually add one by using a Virtual IP (IP Alias). It would then be advisable to use the first /64 of the delegated prefix for that. So if your prefix is 2001:db8:1234::/48, you could use 2001:db8:1234::1/128 as the WAN GUA. Of course this only works if your prefix is more or less static.

Cheers

Maurice

1135

General Discussion / Re: DHCPv4 Server, is it normal to set in this way?

« on: November 15, 2019, 01:45:12 pm »

Should the OPNsense let the DHCP server lease the IPs like xxx.xxx.xxx.0 or xxx.xxx.xxx.255?

Every DHCPv4 server should do this. These are perfectly fine IPv4 addresses within the range you specified. What's wrong with them? What "problem" are you trying to solve?

Cheers

Maurice

1136

General Discussion / Re: Where can I get help?

« on: November 14, 2019, 11:04:03 am »

You can get support by email and phone from Deciso. At "professional" prices of course, but you can buy as little as two hours.

Cheers

Maurice

1137

General Discussion / Re: Unable to pick client prefix: no IPv6 pools on this shared network

« on: November 12, 2019, 01:46:41 am »

Just for my edification, if I were to choose a prefix delegation size of 63, would that make the range ::8 - ::e?

That's correct! That would give you four /63s.
You could also go for eight /64s (::8 - ::f).

And just for clarification: Reserving the first /61 for your LANs is a choice you made. A good choice in my opinion, but not a requirement. You could actually delegate three /62s (::4 - ::c) or six /63s (::4 - ::e) or thirteen /64s (::3 - ::f).

Cheers

Maurice

1138

General Discussion / Re: Unable to pick client prefix: no IPv6 pools on this shared network

« on: November 11, 2019, 07:34:48 pm »

From the above, I'm assuming that I'm being delegated the prefix 2001:db8:a:8030::/60.

Correct.

Given I've already used two /64s in the first /61 for my WIFI and LAN networks, I assume this is referring to the latter /61 (from ::8038 to ::8040) [...]

2001:db8:a:8038::/61 is what you are trying to say.

[...] however in the Prefix Delegation Size dropdown the available options are 48, 52, 56, 60, 62, 63, and 64. Notice there's no 61. Odd?

This dropdown is static and doesn't correspond to your available prefix delegation size. It is considered best practice to only delegate prefixes at nibble boundaries (/48, /52, /56, /60, /64). Not sure why they added /62 and /63, but not /61.

I've selected 62 and entered the tail-end of my range, let's say ::803c - ::8040.

That won't work for two reasons: ::8040 is outside of your /60. And you should only enter the range itself.
You can use ::8 - ::c (two /62s).

AFAIK, there doesn't seem to be an easy way of directly identifying what prefix has been delegated to you

It's unfortunately not explicitly shown in the UI, correct. But you can work it out from the prefix size you request on the WAN and the addresses assigned to your tracking LAN interfaces (like you did).

[Edit]
Oh, and by the way: You can use Request only an IPv6 prefix on the ISP-facing OPNsense's WAN, but not on your lab OPNsense! The way OPNsense does Prefix Delegation requires the DHCPv6 client to also request an address. Otherwise the required route won't be created. I consider this to be a bug, but it has been discussed a long time ago and it seems they won't fix it.
[/Edit]

Cheers

Maurice

1139

General Discussion / Re: Firewall rules, Have I read this wrong or just doing it the hard way

« on: August 01, 2019, 05:39:18 pm »

@johnw230873, we've just recently had this discussion, please see this thread:
https://forum.opnsense.org/index.php?topic=13522

Cheers

Maurice

1140

19.7 Legacy Series / Re: Link-local gateway addresses missing zone index, breaks gateway monitoring

« on: August 01, 2019, 05:23:17 pm »

Looking at your original thread, your issue seems to be caused by the "directly send SOLICIT" option (which I don't use). I don't think it's related to this (fixed) zone index bug. Issue #3604 might indeed be the culprit so better to continue there.

Cheers

Maurice