Topics

1

Virtual private networks / NAT Reflection problem with vpn tunnel that delivers routable ips

« on: April 13, 2021, 11:36:56 am »

hi,

So I have a specific problem which involves NAT Reflection for a vpn link.
This vpn link is not equiped with a private ip but a public routable ip totally open in terms of port.

So an outbound Nat has been activated on the interface associated to this link.
To link my self-hosted VMs, it's going through internal qemu networks linked to the opnsense VM
So there is an interface between the guests and the vpn link interface.

client at 172.20.0.33 -> interface dhcp 172.20.0.31 -> interface openvpn link with the public ip.

I didn't notice at first the NAT reflexion parameters so it was not activated when I did the prot forwarding but even so it has apparently little importance.
The port forwarding is working great.
 
The problem is the NAT Reflexion. I can't do a curl from inside the client to the public ip (which means reaching the client itself) and so I can't make certbot from let's encrypt work.

I'm sure it's the NAT Reflexion since we did some testing and by adding a line to /etc/hosts.conf in this debian VM to the actual domain, I have been able to create a certificate. So the problem is not between the Let'sEncrypt servers and the client but well with the client being able to communicate with itself.

Apparently the parameters when activated, don't do a thing.
I don't see any new rules, I tried to recreate one with the port 80 and 443 but it did the same as before.
I know that some will advise to do splitDNS but before you advise that I suggest you do read about yunohost project.

If you read it carefully you will I think clearly understand why create a dozen of zones files with only one to 3 records in it it's more of a hassle. Plus we should be able to rely on NAT Reflexion too even if some of you don't like it.

So what am I missing here? Which rules or parameters should I activated? Is the problem that here are 2 interfaces here ? or is it something else?

Thanks in advance

2

Virtual private networks / [Solved] not able to reach outside world through openvpn tunnel

« on: April 04, 2021, 02:39:30 pm »

hi,

this setup is a bit maybe complex but for me it's quite simple in the idea.

I've setup a virtual opnsense setup on a isolated server on one of my VLANs which needs to act as a gateway for other VMs on the same server.

Among some gateways there are the WAN, an openvpn to a vpn provider, a wireguard connection to a vpn provider, a openvpn to a foundation that provides me a routable public address.
 
I have problems with that last one.
This openvpn link I want to make it happen through the wireguard link because I don't want them to record my public ip address among other things.
I "think" I succeeded to do that. At least the connection is happening and I'm receiving the public ipv4 and ipv6 that I was supposed to receive.

--------------part one--------------

But my first question is: How can I be sure that it is indeed well executed through the wireguard tunnel already in place?

second question : When I setup the connection I've configured the field of the interface with the wireguard interface. Is that enough ?

The wireguard tunnel has been executed through the excellent script and tutorial here: https://github.com/FingerlessGlov3s/OPNsensePIAWireguard
As you can see, the wireguard tunnel is done through 2 interfaces( the interface that you will assign the new link and the interface of the subnet(s) you want to link to), or 3 if you count the wireguard service.
As you can see also there is an outbound NAT rule for the 500 port for the IKE protocol and for normal usage for all subnets configured in the firewall, which copies both the rules that are automatically generated for WAN.
third question:
I'm not an expert for that the vpn links in that kind of setup so it surprises me that there is a need for a specific port 500 for that since my openvpn setup of the vpn provider didn't need that to make it work. So if someone has documentation or an explanation to give me about that that would be nice 

--------------part two--------------

I don't have communication apparently through the tunnel.
I have deactivated from the original script the pull option which might be the reason because then I guess all routes are not in there but I need your insight for that. And I did that because I was using the pull method then it would screwed my wireguard connection, pull it down, and then go back up because of the script put in place and the monitoring but not the openvpn connection of course.

so first question is : is it because of the absence of the pull option and if yes, how to resolve that?

I can't even ping from the firewall itself using the -S switch of the ping command.

I've tried to reproduce the rules fr the outbound NAT as described here: https://forum.opnsense.org/index.php?topic=4979.0

in place of alias I've tried with any and also with the pre-configured alias of the subnet that I was linking to it. You know the ones that are created when you create an interface, you have always the the interface address entry and the one with the name interface net

I've put a rule also in the firewall to let the traffic goes through it.

So what should I provide as logs? as screenshot maybe ? How can I help to make it determine what's the issue here?


We could say that the part of the openvpn link would ressemble to that schematic.
Where the subgateways are there for handling dhcp, routing to the good interface, portforwarding with outside LAN and so also some NAT and can be linked to the appropriate gateways I want for each subnet.
Maybe it's not the way it should be but that's the more appropriate way I could find to compartimentalize.

I then know that the problem does not reside into the subgateways since it is working with all the other gateways. So I wouldn't understand why not for this one unless you explain it to me.
So I must miss something on the ovpn gateway.
I'm pretty sure this is possible since I'm used to qubes and even if it's a bit of a difference since it's handled by VM's for each connection, it means nevertheless that it is possible.

Thanks for all the help you can give me.

3

21.1 Legacy Series / problem with letting samba through NAT

« on: April 01, 2021, 07:06:47 am »

Hi,

So for this specific setup,
opnsense is a VM which act as a Island firewall to isolate this specific lab of VMs, all hosted on the same server.

I'm trying to let through some samba/cifs shares that I've set up on truenas.
The VM are communicating through virtual network to each other and opnsense is the one with the bridging access to the "outside world".

According to the tcpdump of truenas, there is no packets being received from the outside world on port tcp 445. It is being received if I test it through VMs with smbclient.
I can contact the truenas or other VM with my port forwarding rules I created throuhg SSH.
The rules I created for 445,139,138,137 does look exactly the same besides the fact that I've specified the same port as destination and forwarding.

From what I could read of the live log of the firewall the 445 port was contacted and greenlighted.
So I'm a bit out of leads here.
As I said the rules does seem exactly the same than the SSH ones.
So I would like to rule out any misconfiguration of my behalf or maybe any little specifics that I wouldn't know about opnsense.

For example:
- is there any hard rule that would prevent me to forward cifs ports (MS DS)  maybe ?
- or is it something special to do about it

Thanks in advance for all the leads that you could bring me.

4

French - Français / petite story en lien qui m'est arrivé lros de la récente update

« on: March 15, 2021, 12:05:35 pm »

Historie de pas faire de copier collé:

https://forum.opnsense.org/index.php?topic=22066.0

5

21.1 Legacy Series / little story about a failed upgrade/ Une petite histoire d'un upgrade raté

« on: March 15, 2021, 12:04:24 pm »

Hi guys,

Hope that everyone is okey.

So I was thinking of making this little post to make an echo about this posthttps://forum.opnsense.org/index.php?topic=19159.0.

So I know this ancient post is a bit of a rant but after yesterday I need to say that the upgrade of opnsense i kinda disappointing and I can understand the rant of  this guy.

So saturday I have worked a lot on my new opnsense setup
the setup is a kvm setup on a little homemade rack server under fedora server 33.
I want to specify first that I have several instances of opnsense and it didn't happen with every instances, jthis one was just the worse, others had some other problems but not as dramatic than this one.

the goal of this instance is to put opnsense as firewall of several VMs who are linked to different virtual interfaces in opnsense for different purposes. Some goes through a vpn, others through tor etc.
Opnsense instance is also contained in a VM so every interfaces is virtualized too. the networks linking VMs are also virtualized one and everything is on the same server.

The WAN interface of this instance is a bridge0 interface which normally resides in first position.

So I was working and making a lot of changes in this instance including trying to setup a wireguard setup to vpn server which has a dedicated ip for me and port forwarding . So I made a bunch of rules, port forward rules, etc. All the interfaces were assigned correctly.

I applied the settings of course so everything was running. I didn't backed up the configuration.
there was 2 kernel updates waiting on this fedora server and there was the upgrade to 21.1.3 and I was under 21.1.1 I think?  So not major upgrade normally.

So I've made all the necessary updates and rebooted everything.

What happened do you think?
Well opnsense decided on its own to change the interfaces assignments . There was no more OPT1 -> 4, just a LAN and a WAN where the bridge0 has been assigned to LAN this time.The WAN interface was now the second virtualized interface.
So I couldn't reach opnsense anymore. According to the boot screen, there was no DHCP plan either since LAN was back at 192.168.1.1 .... strange... none of my virt interfaces was using this network and even my WAN before was not using this one.
So no rules, no port forwarding...
I was stucked with my badass password in root so couldn't login like I would be able to do in pfsense for example by using https://docs.netgate.com/pfsense/en/latest/troubleshooting/locked-out.html
By chance I've come up with using the first 3 steps and then logged back in root login screen and reset the password before to reboot in multiuser mode.

So I had also had to use the trick to only assign the WAN interface to retrieve back control of the WEBGUI to see what the damages were.
the openvpn and other packages were still installed.
So not a disk problem. and anyway it's isntalled on 2 new sandisk SSD in RAID1 in a qcow2 file so it can't be that or the file would be simply corrupt.
only everything related to interfaces has disappeared.... firewall, assignments, names, everything...

So I need to re-do everything.

So I can understand how upsetting it is for someone who is not as focused as I am on my tasks to have everything lost.

So I only see 2 possibilities here,
1/ the updates code are really screwed up.
2/ there is some edge conditions where updates through webgui does go to shit... I still can't determine what. But if it is that, then it means that update process is relying on webgui which is horribly wrong since it should be an independent process. So I hope it is not that.

just food for thoughts to the coders of OPNSENSE.
Thanks for reading.


--------------------------------------------FRENCH VERSION ----------------------------------------------------

Bonjour la team,

J'espère que tout le monde va bien.

Donc je pensais à faire un petit écho au post de ce gars là: https://forum.opnsense.org/index.php?topic=19159.0

Je sais que ce post est plutôt un rant de ce gars en question mais je pense qu'il illustre bien ce qui m'est arrivé ce week-end et je ne peux que donner en partie raison à ce gars.

Donc samedi je bossais beaucoup sur cette instance spécifique d'opnsense que j'ai installé sur un server rack conçu moi-même sous fedora 33 server.
Je tiens à préciser avant tout que j'ai plusieurs instances d'opnsense et que j'ai eu ce gros problème qu'avec celle-là. Les autres ont eu aussi des problèmes sur cette mise à jour mais pas aussi gros.

Le but de cette instance est de mette opnsense dans une VM et agissant comme pare-feu pour toute une série d'autres VM sur le même serveur. Ces VM étant connectées par des réseaux générés par kvm-qemu et donc reliées à des interfaces virtuelles de la vm opnsense.
Certaines de ces VM vont à travers des vpns, d'autres tor, etc.

L'interface WAN est donc sur une interface bridge0 qui se trouve en première position dans la liste et donc normalement pour la VM aussi.

Donc je bossais sur beaucoup de changements dans cette instance et notamment faire un lien wireguard entre un serveur et cette instance, qui a une ip dédiée et du port forwarding. Du coup, pas mal de port forward rules, de firewall rules etc .
Tout fonctionnait correctement et les paramètres étaient appliqués et fonctionnels.

J'avais plusierus mises à jours en attente, des kernel update sur le serveur fedora lui-même. Et la mise à jour vers 21.1.3 alors que j'étais sur 21.1.1 d'opnsense il me semble. Donc normalement pas de grosses mise à jour.

J'ai fait tout ça et j'ai rebooté.

Qu'arriva-t-il?

Opnsense n'a plus rien reconnu et a décidé de soi-même que le bridge0 finalement c'était pas assez bien pour le WAN donc il allait le mettre en LAN et plus de WAN plus d'OPT rien.
J'avais évidemment pas sauvegardé ma config sur un fichier.
Il avait purement et simplement réinitialisé toute la config concernant les interfaces et donc les liens entre les interfaces, les règles pare-feu etc.

Alors Je me retrouvais juste avec la console, locked out pusique j'avais un gros mot de passe pour le root. Pas moyen de faire copier coller sur la console. Donc je devais trouver un moyen de réinitialiser le root password.
J'ai donc suivi la doc netgate de pfsense : https://docs.netgate.com/pfsense/en/latest/troubleshooting/locked-out.html
Mais évidemment la dernière étape est pas dispo sur opnsense donc par chance je me suis juste reloggé avec root et je me suis retrouvé sur l'écran de démarrage normal à partir duquel j'ai reset le password.

J'ai reboot en mode multi-user et j'ai utilisé le truc que je dois toujours utiliser en réassignant juste le WAN pour avoir de novueau accès au webgui et de là j'ai pu constater les dégats.

C'était vraissemblablement pas un problème de disques puisque d'une part les paquets que j'avais installé en plus étaient toujours là. D'autres parts ce système est sur deux novueaux SSD sandisk en raid1 et si y avait corruption le fichier qcow2 serait devenu illisible.

Donc je dois faire tout de nouveau.

Donc vous imaginez bien que je peux comprendre la furstration de quelqu'un qui a tout perdu aussi et qui est peut-être moins déterminé sur ses tâches que moi.

Donc il y a deux possibilités ici,
1/ soit le code des updates c'est vraiment de la merde.
2/ soit dans certains cas limites, les updates à travers le webgui font de la merde et je ne sais pas déterminé quoi exactement. Mais si c'est ça, alors ça pose quand même un problème conceptuel qui est que normalement un update process est indépendant du reste. Si c'est pas le cas, c'est vraiment vraiment pas bon.

Doncvoilà de quo ifaire travailler les méninges des codeurs d'Opnsense quand ils auront du temps.
Merci pour votre lecture.

6

Tutorials and FAQs / how to install opnsense on a RAID1 of SSDs

« on: November 21, 2018, 12:52:19 am »

Hi,

I will make a tutorial about it but I'm not so familiar with FreeBSD and certainly not with Opnsense.
What would be your advices on how to do it? Should I create a RAID from the live image first then reboot into the installation mode?
What kind of raid should I use? Should I use mdadm method or should I use the ZFS method?
Just enlighten me on how to do it the best way possible . It's nothing fancy, just a couple of samsung EVO 250G .

EDIT: After ahving some reading of the FreeBSD handbook and noticed finally the GEOM option on the installer, the configuration and the installation was full Auto . Sorry to have missed that.

7

Hardware and Performance / new to opnsens - need hardware advices

« on: February 15, 2018, 09:40:35 pm »

Hi,

I'm new to the concept and use of pfsense - opnsense.
So I would like to be prepare for my futur e FFTH and not being bottleneck on my opnsense project.

I would like to build a box myself.
So I've read some documentation, maybe not enough but I'm trying,s o don't hesitate to point out to me some good ones.

I'm hesitating for the CPU for example, between a xeon E3 and a i7-6700k.
Don't know what's better. Is the ECC capabilities relevant in any kind of usecase in opnsense?
I've read here that the i7 were better than the xeon on the AES capabilities.  Is that still true? https://community.ubnt.com/t5/EdgeMAX/EdgeRouter-4-ER-4-now-available/m-p/2139533/highlight/true#M185779
Plus, I've seen that most of the distributor of appliance for pfsense and opnsense were using i7 more than xeon. In counterpart, the video from LinusTechtips from 2 or 3 years ago, about building the pfsense box, they were using a xeon for that build log.... So what should I take? And based on which argument?

for the motherboard I was thinking about an industrial asrock mb with kvm support?
for the case, I really don't know which one to take. I've read the thread from the guy who was building his own with that : https://www.supermicro.com/products/chassis/1U/512/SC512F-441B . Is that any good? I need one from 1U or 2U but with the dimension to put it in a rack network cabinet which I have. So It's smaller in length than a server cabinet. any recommandation?

Is it possible also to have other things installed than opnsense? Like a hypervisor like kvm-qemu to do some virtualization at the same time or is it not recommanded?

Which addon card for AES maybe or other things? I know that I need top consider buying some good intel NIC but I'm sure there are some thing else?

Thanks in advance for all your answers.
Best regards.