Messages

I found one FW which i don't updated to 24.7.2 because they lost internet connection after reboot, and stuck this weekend on 24.7.1.  Your mentioned config is complete different. Because no confidential data is inside /usr/local/etc/strongswan.conf i paste them here.

FW 24.7.1 with "Automatically generated rules (end of ruleset)" on WAN:

Code Select Expand


# Automatically generated, please do not modify
starter {
    load_warning = no
}
charon {
    threads = 16
    ikesa_table_size = 32
    ikesa_table_segments = 4
    init_limit_half_open = 1000
    ignore_acquire_ts = yes
    syslog {
        identifier = charon
        daemon {
            ike_name = yes
        }
    }
    install_routes = no
    plugins {
    }
}

include strongswan.opnsense.d/*.conf



FW 24.7.2 without "Automatically generated rules (end of ruleset)" on WAN:

Code Select Expand


# Automatically generated, please do not modify
starter {
    load_warning = no
}
charon {
    threads = 16
    ikesa_table_size = 32
    ikesa_table_segments = 4
    init_limit_half_open = 1000
    ignore_acquire_ts = yes
    syslog {
        ike_name = yes
        log_level = no
        daemon {
            app = 1
            asn = 1
            cfg = 1
            chd = 1
            dmn = 1
            enc = 1
            esp = 1
            ike = 1
            imc = 1
            imv = 1
            job = 1
            knl = 1
            lib = 1
            mgr = 1
            net = 1
            pts = 1
            tls = 1
            tnc = 1
        }
    }
    install_routes = no
    plugins {
    }
}

include strongswan.opnsense.d/*.conf


I had here a similar issue with some firewalls which are updated to 24.7.2 (not all)

The issue is between a fw with 24.1.10 and a fresh updated 24.7.2 .

Because first i think thats again a issue on our provider (they hat a bgb router which don't terminate some sessions correctly). So i disabled on both firewalls the corresponding ipsec rules and re-enable them after half an hour. On the status page of both firewalls  the tunnel is "installed" with the correct subnets, but no traffic goes through the tunnel.

on a host on the 24.1.10 net i can start a ping through the tunnel i see also in the log/tcpdump that there is traffic which goes through enc0 but tcpdump on the 24.7.2 on enc0 don't see any traffic. The intresting part is also that under firewall rules the ipsec part is completly missing.

As mentioned under https://forum.opnsense.org/index.php?topic=28326.0 i can see the rules when i call the rules directly. but disable ipsec and re-enabled doesn't help. currently i cannot reboot the 24.7.2.

Edit, Short Update:

If a edit a Rule then the IPSEC Block appears again. And Traffic goes through the VPN Tunnel when i manually add the rules which are previously created via auto rules.

I have a strange issue on one of our opnsense firewalls. And i don't know how to correctly set the title for this issue.

Because of an issue with a bad performance on the site the provider changed the old cablemodem to a new one. The modem provides the public ip to the opnsense via dhcp, so the WAN interface is configured as DHCP client (and not changed during the switch of the modem)

Since then the opnsense looses irregular the network connection. ping of the public and ping of the internal ip on the LAN interface are not possible anymore. the provider says they dont see a problem on there side.

Then 2-3 times powercycle the opnsense (its an apu2) and then it looks stable for hours.

I see in the log many entries like this:

Code Select Expand

<27>1 2023-10-06T23:29:10+02:00 cust-ch-xyz01-fw01.customer.intra dhclient 60785 - [meta sequenceId="1"] Bogus Host Name option 12: cpe_000db94ae4d4 (cpe_000db94ae4d4)
<13>1 2023-10-06T23:29:10+02:00 cust-ch-xyz01-fw01.customer.intra dhclient 56941 - [meta sequenceId="2"] Creating resolv.conf

but this log entries are already there before we switched to the new cablemodem. So i think this is not the issue? but perhaps there is also a solution to fix this?

This night, the connection was lost again around 02:20 o'clock. the opnsense is uptdating itself around thursday on 02:00 o'clock. the reboot was done around 02:17 o clock and as i look into the  system log and see that the wan interface (igb0) looses his connection and also lan (igb1) and then some scripts are triggered, which causes the loose of connections, and so on?

Because also i see something like:

Code Select Expand

<11>1 2023-10-12T02:20:13+02:00 cust-ch-xyz01-fw01.customer.intra opnsense 67423 - [meta sequenceId="71"] /usr/local/etc/rc.linkup: The command '/sbin/ifconfig 'igb1' inet '192.168.123.1'/'24'' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): File exists'

So perhaps some scripts are triggered get stuck?

Currently after a power cycle the opensense come up and then looses his connection and perhaps , some seconds later, it comes back again and is available via network. But it can loos it afterwards again. This morning we needed three

Im currently not at the location and there is no one with a serial cable so view on the console , when connection is lost, is not possible.

The almost complete log of today (until i write this) is attached here.

p.s i changed ip's and so on in the log for privacy.

Oh, i don't see your answer yet. In the meantime (around one day before your post)  i found a solution which works currently perfect for my setup. (its not perfect people who want a clean setup but it works at the moment)

Code Select Expand


#
# Automatically generated configuration.
# Do not edit this file manually.
#

global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin
    nbproc                      1
    nbthread                    1
    hard-stop-after             60s
    maxconn                     10000
    tune.ssl.default-dh-param   4096
    spread-checks               2
    tune.chksize                16384
    tune.bufsize                16384
    tune.lua.maxmem             0
    log                         /var/run/log local0 debug
    lua-prepend-path            /tmp/haproxy/lua/?.lua

defaults
    log     global
    option redispatch -1
    maxconn 5000
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc
    default-server maxconn 5000

# autogenerated entries for ACLs


# autogenerated entries for config in backends/frontends

# autogenerated entries for stats


# Resolver: dc-company-01
resolvers 63d8cfcde3f718.78402437
    nameserver 172.xxx.xxx.yyy:53 172.xxx.xxx.yyy:53
    resolve_retries 3
    timeout resolve 1s
    timeout retry 1s



# Frontend: https_443_frontend (Access to HTTPS Services on Exchange and Matrix Server)
frontend https_443_frontend
    bind 4x.xxx.xxx.xxx:9443 name 4x.xxx.xxx.xxx:9443
    bind 172.xxx.xxx.xxx:9443 name 172.xxx.xxx.xxx:9443
    mode tcp
    default_backend ex-company-01_backend
    # tuning options
    timeout client 30s

    # logging options
    # ACL: sni_check_admin_matrix
    acl acl_63dbd637445d88.60329440 req.ssl_sni -i admin.matrix.customer-domain.net
    # ACL: sni_check_matrix
    acl acl_63dc2304400b73.51558638 req.ssl_sni -i matrix.customer-domain.net
    # ACL: sni_check_element
    acl acl_63dc2313a4d6a3.83535618 req.ssl_sni -i element.customer-domain.net

    # ACTION: check_sni_admin_matrix
    use_backend matrix-company-01_backend if acl_63dbd637445d88.60329440
    # ACTION: check_sni_matrix
    use_backend matrix-company-01_backend if acl_63dc2304400b73.51558638
    # ACTION: check_sni_element
    use_backend matrix-company-01_backend if acl_63dc2313a4d6a3.83535618
    # WARNING: pass through options below this line
    option tcplog
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    http-request set-header X-Real-IP %[src]
   

# Frontend: https_8448_frontend (Matrix Federation Service)
frontend https_8448_frontend
    bind 4x.xxx.xxx.xxx:8448 name 4x.xxx.xxx.xxx:8448 ssl alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/63dbc3b0d08131.92200544.certlist
    mode http
    option http-keep-alive
    default_backend matrix-company-01_federation_backend
    option forwardfor
    # tuning options
    timeout client 30s

    # logging options

# Backend: ex-company-01_backend (Microsoft Exchange 2016 Services)
backend ex-company-01_backend
    # health checking is DISABLED
    mode tcp
    balance roundrobin
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    # WARNING: pass through options below this line
    option ssl-hello-chk
    server ex-company-01_https 172.xxx.xxx.yyy:443

# Backend: matrix-company-01_federation_backend (Matrix Federation Service)
backend matrix-company-01_federation_backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse safe
    server matrix-company-01_federation 172.xxx.xxx.zzz:8080

# Backend: matrix-company-01_backend (Matrix Synapse & Elements Services)
backend matrix-company-01_backend
    # health checking is DISABLED
    mode tcp
    balance roundrobin
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    # WARNING: pass through options below this line
    option ssl-hello-chk
    option forwardfor
    server matrix-company-01_https 172.xxx.xxx.zzz:443 send-proxy-v2


for the matrix server is setup now two ip's on one all "server" in nginx running with:

Code Select Expand

server {
    listen 172.xxx.xxx.zzz:443 ssl http2 proxy_protocol;
    listen 172.xxx.xxx.zzy:443 ssl http2;
    ...
}

one ip is used for external communication from haproxy (the proxy_protocol) and the other for internal communcation from the lan side. so split dns is used here.

Coul'd be that Ex2k16 has proxy support protocol but i think the used iis behind it not, because the former company, who managed this customer used a 2012r2 server for the exchange server (so an other construction side comes up in the next months). I also tried on one apreach to use the iis of the exchange as reverse proxy to the matrix server, which worked expect that some url's which are generated from the matrix server when federation are used, not realy rfc conform are and so wrongly interpreted from iis side and then not correct sended to the matrix server.

Hi,

I searched the forum and read all the threads (with the tutorials) that i found about haproxy configuration, tried different approaches but nothing worked as expected. ssl connection always fails (ex. firefox SSL_ERROR_RX_RECORD_TOO_LONG) or when i try it with openssl s_client to check the certificate it looks like more , no certficate is given or it runs in non-ssl mode or something.

Currently i had a running setup with classic nat directly to a windows exchange 2016 server. Currently the server do the complete let's encrypt stuff by himself and this shoul'd not change. The server is in productive mode and is used internal and externaly. (split dns).

Because their is only one external ip i need to share this ip on port 443, so as i read haproxy is a good solution to solve this. So a secondary server with web services shoul'd be installed now behind the opnsense too.

So for this solution the let's encrypt stuff shoul'd not be happening on the opnsense, the server themselfs shoul'd be maintain the renewal, and so on. So for this the "tcp (layer 4) modes are the way to work with, or are i wrong?

Because the complete stuff on 80 and 443 is productive, i use 9080 and 9443 for testing purposes as ports on the firewall.

Below is my config (some stuff is defined but not used like the resolver currently) . i tried it last evening around 4-5 hours without sucess, so perhaps i oversea something that someone other, which had a working setup, see directly and i don't see it like the trees in the forest. ;-)

Code Select Expand


#
# Automatically generated configuration.
# Do not edit this file manually.
#

global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin
    nbproc                      1
    nbthread                    1
    hard-stop-after             60s
    maxconn                     10000
    tune.ssl.default-dh-param   4096
    spread-checks               2
    tune.chksize                16384
    tune.bufsize                16384
    tune.lua.maxmem             0
    log                         /var/run/log local0 debug
    lua-prepend-path            /tmp/haproxy/lua/?.lua

defaults
    log     global
    option redispatch -1
    maxconn 5000
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc
    default-server maxconn 5000

# autogenerated entries for ACLs


# autogenerated entries for config in backends/frontends

# autogenerated entries for stats


# Resolver: dc-cust-01
resolvers 63d8cfcde3f718.78402437
    nameserver 192.168.99.11:53 192.168.99.11:53
    resolve_retries 3
    timeout resolve 1s
    timeout retry 1s



# Frontend: http ()
frontend http
    bind 192.168.99.1:9080 name 192.168.99.1:9080
    bind 1.x.x.x:9080 name 1.x.x.x:9080
    mode http
    option http-keep-alive
    default_backend ex-cust-01_http_backend
    # tuning options
    timeout client 30s

    # logging options
    option httplog
    # ACL: http_mail_customer_ch
    acl acl_63d834ead32456.82956086 hdr_sub(host) -i mail.customer.ch

    # ACTION: http_mail_customer_ch
    use_backend ex-cust-01_http_backend if acl_63d834ead32456.82956086

# Frontend: https_sni ()
frontend https_sni
    bind 192.168.99.1:9443 name 192.168.99.1:9443
    bind 1.x.x.x:9443 name 1.x.x.x:9443
    mode tcp
    default_backend ex-cust-01_https_backend
    # tuning options
    timeout client 30s

    # logging options
    option tcplog
    # ACL: ssl_hello
    acl acl_63d84150d59f08.49426761 req_ssl_hello_type 1
    # ACL: https_mail_customer_ch
    acl acl_63d83503a02259.11459738 req.ssl_sni -m sub -i mail.customer.ch

    # ACTION: tcp_request_inspect_delay
    # NOTE: actions with no ACLs/conditions will always match
    tcp-request inspect-delay 5s
    # ACTION: tcp_request_content_accept_ssl
    tcp-request content accept if acl_63d84150d59f08.49426761
    # ACTION: https_mail_customer_ch
    use_backend ex-cust-01_https_backend if acl_63d83503a02259.11459738
    # WARNING: pass through options below this line
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    http-request set-header X-Real-IP %[src]

# Backend: ex-cust-01_https_backend (Exchange 2016 - HTTPS)
backend ex-cust-01_https_backend
    # health checking is DISABLED
    mode tcp
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    server ex-cust-01_https 192.168.99.11:443 ssl verify none send-proxy-v2 check-send-proxy send-proxy-v2 check-send-proxy

# Backend (DISABLED): matrix-cust-01_https_backend (Matrix Chat HTTPS)

# Backend: ex-cust-01_http_backend (Exchange 2016 - HTTP)
backend ex-cust-01_http_backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    # WARNING: pass through options below this line
    option forwardfor
    http-reuse safe
    server ex-cust-01_http 192.168.99.11:80

# Backend (DISABLED): matrix-cust-01_http_backend (Matrix Chat HTTP)


on the "ex-cust-01_https_backend" i also tried with and without ssl in the "server" line. the owa, and other services are only via ssl reachable on the server, port 80 always gets empty white pages expect the .well-known directory for let's encrypt.

From my side, the public ip is direct on the firewall, via pppoe. the modem is bridged, and no other ip is configured on the wan side. As julian232 described, it looks like only udp sessions are affected.

Hi,

I have the problem on some opnsense firewall's that when the firewall is restartet, that some yealink phones can't connect anymore to the pbx on the wan side.

The provider told me that three phones can't connect (i dont have access to the phones). When i now check in the firewall  and do a tcpdump i see that the affected phone's try to connect to the pbx. "SIP: REGISTER" is visible on the LAN and also on the WAN side.  They only thing that i see, that the three ip's are with their internal IP's visible on the tcpdump on the pppoe0 interface. Shoul'd that not be the public ip of the firewall as on the other phones?

I also had the same issue on another customer with an internal pbx which connect to the sip provider directly.

I use the default NAT settings. The firewall version is 22.7.9 commit b0c31af1a.

Update/Edit:

After some search i deleted the entries of the affected internal ip in the "Firewall: Diagnostics: States" view and then nat nat worked again. But why this happens and how can we prevent it?

Seit Heute Morgen, wieso auch immer, funktioniert de "One-to-One" NAT nicht mehr auf der einen Firewall.

Es ist so das Auf der Seite der Firewall das LAN 172.23.19.0/24 existiert, sowie die HomeOffice Leute per OpenVPN mit dem LAN 172.23.20.0/24 verbinden. 

Die Firewall wiederum macht zu einer Branchenlösung einen Site2Site Tunnel per IPSEC zum Hersteller der Branchenlösung 10.2.3.0/24. Die Clients im LAN verbinden so auf den RDP Server 10.2.3.10 was ohne Problem klappt. Da der IPSEC Tunnel jedoch nur 172.23.19.0/24 zu 10.2.3.0/24 durchstellt und 172.23.20.0/24 nicht mit gerouted werden kann, hatte ich hier ein wie in der Doku als Beispiel drin ein One-to-One NAT eingerichtet.

Nun ist die Frage, hatte das bisher nur durch Zufall funktioniert, oder liegt der Hund wo anders begraben?

Interface: IPsec
Type: BINAT
External Network: 172.23.19.0/24
Source: 172.23.20.0/24
Destination: 10.2.3.10/32   (Da es nur den RDP Server braucht, dachte ich das reicht)

I have a strange issue on one of our firewalls. i found some nearly similar threads here in the forum, but the solutions their don't work. But it looks like a double-nat asynchronious routing problem, but im'm not the expert here.

On the router of the provider, i had a port forwarding for ipsec and also https and ssh.  (no source ip restrictions possible)

On the firewall i have the rule to allow all traffic from the source ip of our office to the wan interface.

But when i try to connect from the office, the "default deny" rule matches and the traffic is dropped.

I tried with the advanced setting of the rule and the state type "sloppy" and "none" but this don't have any effect.

Internet <=> Provider Router, 192.168.1.1 <=> OPNsense Firewall 192.168.1.128

All IP's are fixed.  Netstat on the firewall told me the following: (The ip's i x-ed are vpn ipsec networks, which currently also not work, the 192.168.9.0 net is the guest wlan)

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS        igb0
10.x.x.x/24        192.168.1.1        US         igb0
127.0.0.1          link#5             UH          lo0
172.21.9.0/24      link#2             U          igb1
172.21.9.1         link#2             UHS         lo0
172.27.x.x/16      192.168.1.1        US         igb0
192.168.1.0/24     link#1             U          igb0
192.168.1.128      link#1             UHS         lo0
192.168.x.0/24     192.168.1.1        US         igb0
192.168.9.0/25     link#8             U      igb1_vla
192.168.9.1        link#8             UHS         lo0

A i was onsite to install the firewall on monday's the connections worked, but now not anymore without a change (until now which i tried with sloppy, and so on).

Genau. Ein User der auf 192.168.18.20 ist versucht auf 123.123.123.123 zuzugreifen.

Ok. In meiner Grafik fehlt noch die virtuelle IP die ich für die Public IP genommen habe.
Daher wenn 192.168.18.20 ins Internet geht, sehen alle Server im Internet die IP 123.123.123.111 (Auch jeder andere Server egal ob LAN oder DMZ der kein 1:1 NAT hat, hat dann diese IP)



Nein Split-DNS ist für uns keine Option, da sich das ganze in einem kleinen DC abspielt und die Grafik nur ein Beispiel ist und das ganze aus noch etwas mehr als nur die beiden Server besteht und somit die Möglichkeit besteht, das in der DMZ Server stehen, auf denen Domains auf den Public IP's laufen, von denen wir nicht wissen (Kunde A) und jemand anderes der nicht weiss, das diese Public IP's in der DMZ ist, dann darauf zugreifen möchte (Kunde B).

Die Antwort z.b wegen schief gehen ist z.b das IMAP Clients nicht verbinden können, oder z.b Firefox eine Meldung bringt wie: "Fehler: Gesicherte Verbindung fehlgeschlagen. Beim Verbinden mit 123.123.123.123 trat ein Fehler auf. PR_END_OF_FILE_ERROR."

Ich sehe halt  auf der Firewall B am Interface em2, das Traffic raus geht und  auch eine Antwort von dieser IP reinkommt. Ebneso sehe ich auf dem Interface em0 der Firewall das Traffic genatted rausgeht und auch, wohl von Firewall B, Traffic reinkommt.

Jedoch sehe ich keinen Traffic wenn ich auf em0 ein tcpdump mache auf 192.168.16.123 und z.b Port 443. Daher irgendwo läuft was auf Firewall A, wo ich keinen Einfluss habe ,und würde daher Regeln auf Firewall B für diesen Fall erfassen, so dass es mir egal sein kann was auf Firewall A läuft wenn ich von Intern mit Public IP in die DMZ möchte.

tcpdump auf em2

Code Select Expand


root@fwl01:~ # tcpdump -ni em2 host 123.123.123.123
10:11:12.008560 IP 192.168.18.20.52432 > 123.123.123.123.443: Flags [SEW], seq 1018338325, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:11:12.008781 IP 123.123.123.123.443 > 192.168.18.20.52432: Flags [R.], seq 0, ack 1018338326, win 0, length 0
10:11:12.010486 IP 192.168.18.20.52434 > 123.123.123.123.443: Flags [SEW], seq 432463161, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:11:12.010630 IP 123.123.123.123.443 > 192.168.18.20.52434: Flags [R.], seq 0, ack 432463162, win 0, length 0
10:11:12.505816 IP 192.168.18.20.52434 > 123.123.123.123.443: Flags [S], seq 432463161, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:11:12.506073 IP 123.123.123.123.443 > 192.168.18.20.52434: Flags [R.], seq 0, ack 1, win 0, length 0
10:11:12.507836 IP 192.168.18.20.52432 > 123.123.123.123.443: Flags [S], seq 1018338325, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:11:12.507986 IP 123.123.123.123.443 > 192.168.18.20.52432: Flags [R.], seq 0, ack 1, win 0, length 0
10:11:13.007915 IP 192.168.18.20.52432 > 123.123.123.123.443: Flags [S], seq 1018338325, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:11:13.008166 IP 123.123.123.123.443 > 192.168.18.20.52432: Flags [R.], seq 0, ack 1, win 0, length 0
10:11:13.011887 IP 192.168.18.20.52434 > 123.123.123.123.443: Flags [S], seq 432463161, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:11:13.012054 IP 123.123.123.123.443 > 192.168.18.20.52434: Flags [R.], seq 0, ack 1, win 0, length 0


tcpdump auf em0

Code Select Expand


root@4fwl01:~ # tcpdump -ni em0 host 123.123.123.123
10:11:12.008630 IP 192.168.16.2.51745 > 123.123.123.123.443: Flags [SEW], seq 1018338325, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:11:12.008764 IP 123.123.123.123.443 > 192.168.16.2.51745: Flags [R.], seq 0, ack 1018338326, win 0, length 0
10:11:12.010519 IP 192.168.16.2.17102 > 123.123.123.123.443: Flags [SEW], seq 432463161, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:11:12.010618 IP 123.123.123.123.443 > 192.168.16.2.17102: Flags [R.], seq 0, ack 432463162, win 0, length 0
10:11:12.505872 IP 192.168.16.2.13774 > 123.123.123.123.443: Flags [S], seq 432463161, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:11:12.506053 IP 123.123.123.123.443 > 192.168.16.2.13774: Flags [R.], seq 0, ack 432463162, win 0, length 0
10:11:12.507874 IP 192.168.16.2.31987 > 123.123.123.123.443: Flags [S], seq 1018338325, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:11:12.507974 IP 123.123.123.123.443 > 192.168.16.2.31987: Flags [R.], seq 0, ack 1018338326, win 0, length 0
10:11:13.007983 IP 192.168.16.2.11287 > 123.123.123.123.443: Flags [S], seq 1018338325, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:11:13.008137 IP 123.123.123.123.443 > 192.168.16.2.11287: Flags [R.], seq 0, ack 1018338326, win 0, length 0
10:11:13.011922 IP 192.168.16.2.55533 > 123.123.123.123.443: Flags [S], seq 432463161, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:11:13.012037 IP 123.123.123.123.443 > 192.168.16.2.55533: Flags [R.], seq 0, ack 432463162, win 0, length 0


Hier noch die FW Regeln von Firewall A:




Edit:  In der Grafik ist die falsche IP drauf, weil ich die falsch editiert habe, müsste schon die selbe sein.

Wegen Hybrid NAT, das ist aktuell auf Standard mit nur die automatischen Regeln (Könnte manuelle erfassen), da meine Versuche alle nicht gefruchtet hatten und ich darum die Regeln wieder gelöscht hatte, nicht das dadurch dann andere Dinge, die aktuell funktionieren, nicht mehr funktionieren.

Ok. Ich habe mal versucht das ganze grob aufzuzeichnen.



Und eben das Problem ist halt z.b das wenn ich von 192.168.18.20 auf 123.123.123.123 zugreifen möchte,
halt dann bei Firewall A wohl lande. Da habe ich leider keine Möglichkeit tcpdump zu machen aber sehe den Traffic halt bei Firewall B rausgehen über em0, und es kommt dann auf dem Interface auch was zurück aber wohl komplett schief. Weil halt z.b Port 80, 443 was offen ist von Extern z.b fürs Webmail, nicht funktioniert. Ebenso IMAP.  Aber wenn ich halt vom WAN komme, daher nicht vom Terminal Server geht alles wie gewünscht.

Ich habe das Problem das ich bei einem Setup nicht um ein Double NAT herum komme.

Auf der ersten Firewall (Sehr mininmal und kaum Einstellmöglichkeiten) habe ich ein DNAT und SNAT von Public IP auf virtuelle IP's der OPNsense eingerichtet. Die wiederum ein 1:1 NAT auf den Host in der DMZ macht. Das funktioniert soweit gut. Ich sehe in der DMZ die richtigen IP's der Clients auf dem Server aber auch wenn ich vom Server ins Internet verbinde, sehe ich die richtige zugewiesene fixe IP Adresse. Die OPNsense Firewall kennt in diesem Szenario die wirkliche Public IP gar nicht, da sie selber am WAN Interface mit Internen virtuellen IP's arbeitet die 1:1 genatted sind auf der ersten Firewall.

Nun ist das Problem aber das ich ein LAN auf der OPNsense habe und die auch auf gewisse Dienste zugreifen müssen und ich würde das ganze wenn möglich mit NAT lösen oder Routing lösen am LAN Interface. (DNS, etc. will ich nicht umbiegen) Braucht es da zwingend eine virtuelle IP der Public IP am LAN Interface, oder geht das auch ohne, das ich einfach eine NAT Regel einrichte, das wenn eine Anfrage vom LAN an die Public IP kommt, die Firewall ein NAT durchführt und das ganze so dann in die DMZ schickt und die DMZ über die FW das wieder zurück, da ich nicht möchte, das der Host der DMZ die LAN IP des Clients sieht.

Ich habe verschiedenes ausprobiert, aber das Gefühl das ich vor Lauter Bäumen den Wald nicht sehe, oder das gewünschte Setup so wirklich nicht geht.

We had the problem, that since our firewall updated to 19.1.4 our ipsec tunnel's don't work anymore as expected. We see on the GUI that all tunnels are up and on both sites we see status up on both phase. But we don't see any traffic through the tunnel. I can ping from my host on site A to the firewall or the server of site B and i don't see any traffic on Site B, i only see with tcpdump my ping request on the Firewall of site A but nothing more. We also rebooted the firewall but no effect.

Edit:
Site B ist still on version 19.1.2 and when i ping from Site B to Site A i see in tcpdump on interface enc0 ping ping request on site A and Site B. When i do a ping from Site A, i don't see this ping on enc0. Only on the LAN interface and then it goes to nowhere.

I have some issue's too, with OPNsense 19.1.1

I updated from 19.1 after the other export bug with the UDP string in the export file, now this look's correct but in the .p12 file, some certificates from the certificate chain's are missing and the windows openvpn client gives an error, that he cannot verify the certificate and don't establish a successfull connection.