Docs/OPNsense: Difference between revisions

From MTU LUG Wiki
Jump to navigation Jump to search
No edit summary
 
(10 intermediate revisions by 3 users not shown)
Line 1: Line 1:
'''For Layer 1 network details, see [[Docs/Cables]].'''
[[Docs|<small>~/Docs</small>]]

'''For Layer 2 network details, see [[Docs/Switches]].'''


OPNsense is our router/firewall.
OPNsense is our router/firewall.
Line 5: Line 7:
We have two OPNsense devices, Lasagna and Ravioli.
We have two OPNsense devices, Lasagna and Ravioli.


=== Firewall Rules ===
== Network ==

View the WebUI for the specific firewall rules, but some of the more basic/essential ones are:
=== Management (OOB) ===
{| class="wikitable"
!Subnet
|-
⚫
|10.10.0.0/24
|}
⚫
OOB Management services like [https://www.dell.com/en-us/lp/dt/open-manage-idrac Dell iDRAC] / [https://www.hpe.com/us/en/hpe-integrated-lights-out-ilo.html HP iLO] and internal networking hardware.

⚫
Management cannot communicate with LAN/WAN.

⚫
Generally, Management should be restricted from everything else.

⚫
OOB services tend to be ''super'' vulnerable, there are dozens of [https://github.com/mgargiullo/cve-2018-1207 premade scripts] that instapwn iDRACs and give you a root shell by just pointing them at the IP address.

⚫
Because of this, the iDRAC web login interface should only be accessible to anyone you're okay having root on the server.

⚫
=== LAN ===
{| class="wikitable"
!Subnet
|-
⚫
|10.10.1.0/24
|}
Servers and Virtual Machines.

LAN cannot communicate with Management.

=== WAN ===
{| class="wikitable"
!Subnet
!Main WAN IP
|-
|141.219.180.64/27
|141.219.180.69
|}
Our public IP subnet under Tech's <code>141.219.0.0/16</code> block.

⚫
The plan is to use reverse-NAT to map the public IPs to select internal IPs, since we won't have enough IPs for every VM.

=== OpenVPN ===
{| class="wikitable"
!Subnet
|-
|10.10.10.0/24
|}


OpenVPN can be used as a secondary admin/user option compared to wireguard or can be used for homelab routing. This allows devices on a members network to communicate directly with lug devices, depending on what is configured on the user side and the server's side.

⚫
=== Wireguard ===
{| class="wikitable"
!Subnet
|-
|10.10.11.0/24
|}
⚫
<code>10.10.11.0/25</code> - Wireguard admin range (access to LAN+Management)

⚫
<code>10.10.11.128/25</code> - Wireguard user range (access to only LAN)


All members can request 'user' wireguard configurations to connect to LUG infrastructure. These 'user' configs are restricted to LUG's LAN network only. (due to the aforementioned iDrac exploit issues).
⚫
# Management cannot communicate with LAN/WAN (the internet), and LAN cannot communicate with Management.
⚫
## Generally, Management should be restricted from everything else. (maybe even other iDrac servers?)
⚫
## OOB services tend to be ''super'' vulnerable, there are dozens of [https://github.com/mgargiullo/cve-2018-1207 premade scripts] that instapwn iDRACs and give you a root shell by just pointing them at the IP address.
⚫
## Because of this, the iDRAC web login interface should only be accessible to anyone you're okay having root on the server.
⚫
# Wireguard
## The admin/user split is so all members can be given a wireguard config to the internal network without having to worry about them being able to trivially get root on all servers running premade-exploits like [https://github.com/mgargiullo/cve-2018-1207 these] on the iDracs.
## If someone shows up to a couple meetings they're probably fine to get an admin config; this is more for peace-of-mind to not need to worry about the configs given to people who went to one meeting once at the beginning of the semester and have never been seen again.
## Neither config should have access to WAN, just to prevent someone getting LUG in hot water if they attempt to torrent or something similarly dumb through the VPN.


Neither wireguard config should have access to the internet and are not intended for standard VPN traffic through LUG as an exit.
⚫
=== Routing ===


Endpoint networks can be configured as needed but OpenVPN may be preferred for this usecase as LUG/users can dynamically change routes/receive DHCP updates.
==== Main networks ====
We have two main networks:
⚫
* 10.10.0.0/24 - Management (OOB Management services like [https://www.dell.com/en-us/lp/dt/open-manage-idrac Dell iDRAC] / [https://www.hpe.com/us/en/hpe-integrated-lights-out-ilo.html HP iLO])
* 10.10.1.0/24 - LAN (servers/VMs)
We may also be getting a <code>/27</code> of Tech's <code>141.219.0.0/16</code> block through IT (~28-30 usable public IP addresses).


=== pfsync ===
⚫
The plan is to use reverse-NAT to map the public IPs to select internal IPs, since we won't have enough IPs for every VM (so we can't do it like IT and exclusively use publicly routable addresses).
{| class="wikitable"
!Subnet
|-
|10.10.250.0/24
|}
Interface used for High Availability (HA) sync between the 2 firewalls.


Cannot communicate with any other subnet.
==== VPN Networks ====
In addition, there are two main VPN networks:


== OPNSense ==
⚫
* 10.10.10.0/24 - OpenVPN
<Rules for access, updates, generating wireguard configs, etc>
⚫
* 10.10.11.0/24 - Wireguard
⚫
** 10.10.11.0/25 - Wireguard admin range (access to Management+LAN, no WAN)
⚫
** 10.10.11.128/25 - Wireguard user range (access to only LAN, no WAN)

Latest revision as of 22:42, 1 July 2026

For Layer 1 network details, see Docs/Cables.

For Layer 2 network details, see Docs/Switches.

OPNsense is our router/firewall.

We have two OPNsense devices, Lasagna and Ravioli.

Network

Management (OOB)

Subnet
10.10.0.0/24

OOB Management services like Dell iDRAC / HP iLO and internal networking hardware.

Management cannot communicate with LAN/WAN.

Generally, Management should be restricted from everything else.

OOB services tend to be super vulnerable, there are dozens of premade scripts that instapwn iDRACs and give you a root shell by just pointing them at the IP address.

Because of this, the iDRAC web login interface should only be accessible to anyone you're okay having root on the server.

LAN

Subnet
10.10.1.0/24

Servers and Virtual Machines.

LAN cannot communicate with Management.

WAN

Subnet Main WAN IP
141.219.180.64/27 141.219.180.69

Our public IP subnet under Tech's 141.219.0.0/16 block.

The plan is to use reverse-NAT to map the public IPs to select internal IPs, since we won't have enough IPs for every VM.

OpenVPN

Subnet
10.10.10.0/24


OpenVPN can be used as a secondary admin/user option compared to wireguard or can be used for homelab routing. This allows devices on a members network to communicate directly with lug devices, depending on what is configured on the user side and the server's side.

Wireguard

Subnet
10.10.11.0/24

10.10.11.0/25 - Wireguard admin range (access to LAN+Management)

10.10.11.128/25 - Wireguard user range (access to only LAN)

All members can request 'user' wireguard configurations to connect to LUG infrastructure. These 'user' configs are restricted to LUG's LAN network only. (due to the aforementioned iDrac exploit issues).

Neither wireguard config should have access to the internet and are not intended for standard VPN traffic through LUG as an exit.

Endpoint networks can be configured as needed but OpenVPN may be preferred for this usecase as LUG/users can dynamically change routes/receive DHCP updates.

pfsync

Subnet
10.10.250.0/24

Interface used for High Availability (HA) sync between the 2 firewalls.

Cannot communicate with any other subnet.

OPNSense

<Rules for access, updates, generating wireguard configs, etc>

Retrieved from "https://lug.mtu.edu/w/index.php?title=Docs/OPNsense&oldid=8128"