Messages

Hi all,

i have a vpn gateway (22.7.6) with two ipsec tunnels.

A---B (route based (VTI), IKEv2, old style)
B---C (policy based, IKEv2)

And i would like to route traffic from A to C:

A---ipsec-route-based---B(BINAT)---ipsec-policy-based---C

Is this generally possible? Can it even work that way?

I successfully did something similar in connecting two policy based tunnels (ipsec, IKEv2). With BINAT and "Manual SPD entries".

Here I have tried to do the same.
A BINAT rule, to nat the source ip address from A to an address, which maps the policies of B---C. And the source ip address of A in "Manual SPD entries" of phase-2 setting of B---C.

A---B works, B---C likewise, but
Traffic from A---C is visible on the ipsec-interface of B for tunnel A---B,
after that nothing more.
No logging of BINAT, and no routing into the tunnel B---C.

Best regards
eell

Hallo Zusammen,

ich habe ein VPN-GW (22.7.6) mit zwei IPsec-VPNs.
A---B (route based)
B---C (policy based)
Und ich möchte Traffic von A nach C routen:

A---ipsec-route-based---B(BINAT)---ipsec-policy-based---C

Kann das überhaupt funktionieren?

Mit zwei policy-based IPsec-VPNs habe ich so ein Setup mittels BINAT und "Manual SPD entries" hinbekommen.

Hier habe ich das analog versucht:
BINAT-Regel, mit der die Quell-IP-Adresse von A auf eine Adresse genatet wird, die zu den Policies zu B---C passt. Quell-IP-Adresse von A in "Manual SPD entries" von Phase-2-Eintrag.

A---B funktioniert, B---C ebenfalls, aber
Traffic von A---C sieht man am IPsec-Interface des VPN A---B, danach passiert aber scheinbar nichts mehr.
Es wird kein BINAT geloggt, und es wird nicht nach B---C geroutet.

Gruß
eell

Thank you Hannes,

worked like a charm. I did not try 22.1 as you did this already. But i filed a bug report: #5960

Best regards

Das ist wohl ein Bug, und wie Hannes in
https://forum.opnsense.org/index.php?topic=29798.0
herausgefunden hat, wäre ein einfacher Workaround die alte strongswan.conf-Konfiguration (oder den fehlenden Teil) in den Custom-Bereich zu kopieren (/usr/local/etc/strongswan.opnsense.d/).

Thanks, this is helpful. I have >30 entries in "subnet" and "split-include".

Did you copy the whole content of strongswan.conf into include.conf, or just the missing part?

What would also interest me is whether this behaviour is a "feature" or a bug. I will probably try vs. 22.1.10 in the evening.

Hallo,

ich habe ein Opnsense-VPN-Gateway von vs. 19.1.10 auf 22.7.1 gebracht, durch Neuinstallation mit Konfig-Restore.

Das einzige, was jetzt nicht funktioniert ist, dass mein IPsec-Client (macOS 12.5) zwar die VPN-Verbindung aufbaut, aber keine Routing-Information erhält.

Die Option "Provide a list of accessible networks to clients" ist angewählt.

Bisher hatte die strongswan.conf in "plugins" zwei Attribute "subnet" und "split-include", die jetzt fehlen:


...
plugins {
        attr {
            subnet = ...
            split-include = ...
            dns = 9.9.9.9
            # Search domain and default domain
            28674 = bla.bla
            28675 = bla.bla
            25 = bla.bla
            28673 = 1
        }
        xauth-pam {
            pam_service = ipsec
            session = no
            trim_email = yes
        }
    }
...

Ist das ein bekannter Fehler in der Version, oder habe ich etwas übersehen und das funktioniert jetzt anders?

Viele Grüße

Danke, für den Tipp mit Neuinstallation/Konfig-Restore, das hat hier auch mit dem großen Sprung tadellos geklappt.

Das ist hier sicher gegenüber vielen Teilupdates von Minor- und Major-Releases das bessere Verfahren.

Danke, ich probier's aus und melde das Resultat zurück.

Hallo,

ich habe eine "OPNsense 19.1.10_1-amd64"-VM, die ausschließlich Packetfiltern und etwas IDS macht, und möchte diese auf 22.7 heben. Welche Möglichkeiten habe ich?

Auf der Konsole oder in der GUI wird mir ein Upgrade auf 19.7 angeboten. Bedeutet das, dass ich mich von einem Major-Release zum nächsten hangeln muss? Oder funktioniert das irgendwie auch in "einem Rutsch"?

Ist in diesem Fall auch die Neuinstallation mit Importieren der Konfiguration eine Option, oder kann man das vergessen?

Oder ist es am Ende sinnvoller die VM "from Scratch" neu aufzubauen?

Danke und Gruß

Hallo zusammen,

auf einer von 3 Opnsense-Installationen wächst flowd.log bis die Platte voll ist.
OPNsense 19.1.9-amd64 auf einem ESXi-Server mit 3 Interfaces (DMZ + 2x LAN), NAT auf DMZ-Interface und IPS aktiviert.

Nach einem reboot mit gelöschten flowd.log* und leerem /var/netflow läuft alles normal mit laufendem flowd und flowd_aggregate.py. Nach einigen Minuten beginnt flowd.log mit einigen kB/Minute zu wachsen. Irgendwann plötzlich beansprucht flowd_aggregate.py 100% eines cores und flowd.log wächst mit >10MB/Minute bis die Partition voll ist, dabei wird auch nicht mehr rotiert.

Auf 2 anderen Opnsense-Gateways (1 externe fw mit IPS, 1 reines VPN-Gateway) habe ich das Problem nicht.

Hat jemand einen Tipp wie man flowd_aggregate.py genauer auf die Finger sehen kann (Debug-Log, o.ä.)?

Edit:
Mit deaktiviertem IDS/IPS verhält sich das fast so wie es soll - die flowd.log-Files werden rotiert, sind aber meist noch > 10 MB groß.

Ist das normal, dass flowd_aggregate.py mit aktiviertem IDS so viel Rechenzeit benötigt? Oder habe ich zuviele IDS-Rulesets aktiviert?

  PID USERNAME       THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
24835 root             1 102    0 36572K 32208K CPU3    3 143:23 100.39% python2.7
78080 root             7  20    0  1759M   359M nanslp  1   0:48   1.24% suricata