Messages

Outre le fait que je ne comprends pas pourquoi tu as posté ça en réponse à ce post, je ne crois pas non plus que ce soit approprié en tant que nouveau post.

Aucune mention d'OPN, tes soucis ont l'air d'être entièrement sur Proxmox (qui a ses propres forums).
En fait, ce serait presque mieux sur Debian parce que je soupçonne que ce n'est pas spécifique à Proxmox non plus.

OPN blocks whatever you tell it to block.
The default anti-lockout rules actually prevent redirection of 80, 443 and 22 on one interface (various ways to tweak that).
I don't recall how these rules end up looking like on a transparent bridge...

But I don't see how the VPN could work.
Even if the decapsulated traffic was "routed" to the bridge, the source address would be a 10/8. The replies would not make it back IMO.
I suspect your VPN appliance has an IP within the target network.

Are you sure you can't use OPN as a router without NAT?

What's the IP range for LAN? Double check the 'Lan network' alias in FW > Diagnostics.
You have floating rules. Is there one with the same description?
Or verify the rule that is identified from the i icon at the end of the log line (follow the rid).

I had lost context on this thread and it's a long read...

I'm still confused about the topology.
Are you saying OPN was setup as a transparent filtering bridge (essentially a switch with 2 ports allowing filtering)?
The "various machines" behind the physical switch have public IPs because they are directly on the network of your ISP. Correct?

Then you add a VPN interface to the mix, with a transfer network that has a private IP range, and you expect to be able to manage the "various machines" from that transfer network.
Your VPN endpoint is accepting connection from many places, and your "various machines" should only be manageable from the VPN network.
That's the idea?

Ping is a low bar. Do you get IP via DHCP in the expected range?
Did you have a specific rule to allow GUI access or did you rely on the anti-lockout rule?

I've done several of these hardware changes (eg. passthrough to bridge under proxmox, virtualized to bare metal).
I typically boot the target device enough to see what the network device naming scheme is, then do a search/replace on the old config (e.g. vtnet -> igc) then import during install. It's been pretty seamless (apart from missing plug-ins, in particular when it's AGH configured as DNS).

...
Using verbose boot it errors and stops at trying to initializing the uart on the motherboard, no actual serial port on the board but a uart header. I haven't tried attaching a serial adapter to the uart yet since I don't remember where I put them.
...

That's the kind of clue I was after. There have been several threads about these uart settings over the past few weeks.

IIRC, the static mappings are picked up from the config.xml directly so it applies to all DHCP servers managed through the GUI.
Unbound restart is required. Hostname required too.

OTOH, if you forward to Dnsmasq for local resolution, reading these mappings does not seem very useful...

I'm not opening that coordinator link and all info on that product seems to be in Russian anyway.
I'll assume some sort of overlay network to establish site to site connectivity. Is it essentially a VPN appliance?

I assume the loop is completed over the internet. That initial diagram is clearly missing pieces...
Do you confirm?
There's another router with internet connectivity in OrgB? OPN as well?

And please attach screenshots directly to your reply (using preview or reply, versus quick reply).
I'm not following another link in this thread.

Personally, I don't get the overall topology.

OrgA (Right):
The FW icon is OPN, right?
With 3 interfaces?
* WAN - 192.168.0.254/24
* LAN - 172.17.32.1/21
* KSPD_A - 10.62.65.254/24

OrgB (Left) has one interface KSPD_B - 10.62.70.254/24
Clarity was be improved if interfaces had different names in both orgs... We're looking at screens and it's not obvious which side they belong too.

...
Both organizations use a coordinator to communicate with each other via the KSPD channel.

What does that mean?

And then there's a machine in OrgA that's dual homed (on LAN & KSPD)???

A picture of the screen might contain some clues...
You have disclosed so little information.

Ah, the xtra interface was not on the topology diagram... 😉
With a source in the same subnet, reply traffic was probably directed to that interface indeed.

If the OP really had the config described in it (WAN and LAN getting DHCP IP from your edge router), that is so invalid that it's not even worth trying to understand how rules fired or not. I'd consider that part resolved as well.

But it's completely up to you. Most folks don't bother marking threads solved.
It could save some time for other folks looking to help. I think we're done on this thread.

FYI, 'WAN Address' is the IP assigned to the WAN interface likely via DHCP.
'This Firewall' is the collection of IPs assigned to all interfaces.
Using 'This Firewall' makes sense for FW rules where an IP associated with the FW might do.
It makes less sense on a port forward on a single interface where only one of the IPs is relevant.

It looks to me like no traffic is coming back from the Linux VM.
Have you confirmed outbound network connectivity from that VM (IP, ping, DNS, light browsing) as a way to establish some baseline on network connectivity?
Have you confirmed that you can connect to it from its LAN? Or even just from OPN?

Is sshd even installed and running?

Code Select Expand

systemctl status sshd

Edit:
That last screenshot is ssh into OPN? It looks rather healthy.

Active le logging pour les règles par défaut (Firewall: Settings: Advanced).
Regarde le log live quand tu démarres le client mail.

Si le pare-feu est le souci, tu devrais voir du rouge.
Les ports pour le courriel sont standard (SMTP = 25, IMAP = 143, various for POP). Ça dépend du service que tu utilises.

Si tu ne sais pas créer la règle pour compenser, partage une copie d'écran du traffic bloqué (tu peux filtrer le log live).

Ping and tracert should work FROM a IPv4 host in LANDMZ because of this:

Code Select Expand

AB Protocol     Source     Port Destination Port Description
A  IPv4 ICMP    LANDMZ net *    *           *    Allow ICMP to OPNsense 
At least, it should go through the FW.
There's not enough info in this thread to infer what 192.168.11.1 maps to.

Then I was saying that this makes sense (option A):

Code Select Expand

AB Protocol     Source     Port Destination Port Description
...
B  IPv4+6 *     LANDMZ net *    RFC1918     *    Block LANDMZ to internal  # Explicit block of inter-VLAN
A  IPv4+6 *     LANDMZ net *    *           *    Allow access to everything

This is an alternative (option B):

Code Select Expand

AB Protocol     Source     Port Destination Port Description
...
A  IPv4+6 *     LANDMZ net *    !RFC1918    *    Allow access to everything except local networks

One big difference is that when it is followed by this:

Code Select Expand

AB Protocol     Source     Port Destination Port Description
...
A  IPv4 *       LANDMZ net *    FLUX_IPs    *    Allow to admin PC only    # Isn't the Block RFC1918 rule getting in the way?   
Assuming FLUX_IPs is a subset of RFC1918 (give the admin PC description), option A will prevent that rule from going into effect while option B won't.
If that rule was higher up (before the block), it would also work.

So one part of my comments was about some redundancy (block 1918, allow !1918), another was about an unreachable rule (block 1918, allow IPin1918).

Please attach screenshots using preview or reply (vs. quick reply).
As of now, your 3rd party links are hit and miss...

The 2nd "manual anti-lockout" should be sufficient. As is, you won't see stuff in the logs because logging is not enabled on it.
Nothing should end with a default deny with these rules. More don't have logging and some of them don't have description (makes troubleshooting harder).

In the PF rule, I'd use "WAN Address" and add a description.

Given the live view logs, traffic passed through the FW (in on WAN, out on ServerAndNAS).
The next step is to do a packet capture to see if anything is coming from the ssh server.
It's in interface diagnostics. Capture the WAN and LAN side for port 22 (it would be easier if the WAN port was also the standard 22).

More tomorrow. It's late...