Topics

1

24.7 Production Series / Strange IPv6 behavior with avahi-daemon (on TrueNAS)

« on: July 20, 2024, 09:00:19 pm »

Hello,

after upgrading to 24.7 something strange is happening with my TrueNAS environment:

Code: [Select]

Jul 18 19:30:48 erebos avahi-daemon[4206]: Registering new address record for fd33:bcd:30fc:9e4b:be24:11ff:feef:9582 on enp6s18.*.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Registering new address record for fe80::be24:11ff:feef:9582 on enp6s18.*.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Withdrawing address record for 2003:ef:bf13:a200:be24:11ff:feef:9582 on enp6s18.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Withdrawing address record for fe80::be24:11ff:feef:9582 on enp6s18.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Withdrawing address record for 10.0.0.4 on enp6s18.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Host name conflict, retrying with erebos-2
Jul 18 19:30:48 erebos avahi-daemon[4206]: Registering new address record for fd33:bcd:30fc:9e4b:be24:11ff:feef:9582 on enp6s18.*.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Registering new address record for 10.0.0.4 on enp6s18.IPv4.
Jul 18 19:30:49 erebos avahi-daemon[4206]: Server startup complete. Host name is erebos-2.local. Local service cookie is 1161687643.
Jul 18 19:30:50 erebos avahi-daemon[4206]: Service "erebos-2" (/services/SMB.service) successfully established.
Jul 18 19:30:50 erebos avahi-daemon[4206]: Service "erebos-2" (/services/HTTP.service) successfully established.
Jul 18 19:30:50 erebos avahi-daemon[4206]: Service "erebos-2" (/services/DEV_INFO.service) successfully established.
Jul 18 19:30:50 erebos avahi-daemon[4206]: Service "erebos-2" (/services/ADISK.service) successfully established.
Avahi is the implementation of the Apple Bonjour protocol or MDNS stuff; widely used by systems within the BSD & Linux ecosystem to allow e.g. SMB shares to be discovered by Apple devices.
This messages appeared when I restarted the opnsense the last time; a reboot of the TrueNAS is fixing the issue for the Mac devices because the correct name is online again.

I checked my logs of the TrueNAS system and it started to produce this messages at nearly every restart of the opnsense after when I upgraded to 24.7; that's why I'm asking here and not in the TrueNAS community...

To my setup:
My TrueNAS get a IPv4 address via a static lease from ISC DHCP, IPv6 is configured by "Track interface" on the LAN side and DHCPv6 on the WAN side (PPPoE connection to Telekom Germany).

From my perspective there is something strange going on in 24.7 regarding IPv6, as I also noticed after a reboot that the IPv6 address on the WAN side is active for a second before disappearing for XYZ minutes.
Also the opnsense is not able to get the gateway for IPv6; but the clients get a IPv6 address and are able to use it.

If you need some logs from the opnsense, just say it and I will provide it.

Thanks a lot,
Alex

2

24.7 Production Series / Kernel panics after upgrade to R1

« on: July 16, 2024, 08:21:29 pm »

Hello,

after updating today from 24.1.10 to 24.7.r1 I had some Kernel panics:

Code: [Select]

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 06
fault virtual address = 0x20
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80c1dfd0
stack pointer         = 0x28:0xffffffff82841df0
frame pointer         = 0x28:0xffffffff82841e00
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 7 (pf purge)
rdi: 0000000000000000 rsi: 0000000000000000 rdx: fffff80001d15740
rcx: fffff80001d15740  r8: 0000000000003000  r9: 000000000000000f
rax: 0000000000000000 rbx: 0000000000000000 rbp: ffffffff82841e00
r10: fffff801f0ef8000 r11: 000000008083bf61 r12: 0000000000000000
r13: fffff80001d15740 r14: 0000000000000000 r15: 000000000001432c
trap number = 12
panic: page fault
cpuid = 3
time = 1721152911
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff82841ae0
vpanic() at vpanic+0x131/frame 0xffffffff82841c10
panic() at panic+0x43/frame 0xffffffff82841c70
trap_fatal() at trap_fatal+0x40b/frame 0xffffffff82841cd0
trap_pfault() at trap_pfault+0x46/frame 0xffffffff82841d20
calltrap() at calltrap+0x8/frame 0xffffffff82841d20
--- trap 0xc, rip = 0xffffffff80c1dfd0, rsp = 0xffffffff82841df0, rbp = 0xffffffff82841e00 ---
turnstile_broadcast() at turnstile_broadcast+0x40/frame 0xffffffff82841e00
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x73/frame 0xffffffff82841e30
pf_unlink_state() at pf_unlink_state+0x338/frame 0xffffffff82841e70
pf_purge_expired_states() at pf_purge_expired_states+0x178/frame 0xffffffff82841ec0
pf_purge_thread() at pf_purge_thread+0x13b/frame 0xffffffff82841ef0
fork_exit() at fork_exit+0x7f/frame 0xffffffff82841f30
fork_trampoline() at fork_trampoline+0xe/frame 0xffffffff82841f30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
My first experience was that it is only happening directly after a reboot, but now after some hours without any issue, it happen without any interaction from my side.

I will try to disable some tunables from 24.1 which are currently not required, as e.g. the Microcode upgrade is still active (and it seems like the boot process try to update it...):

Code: [Select]

CPU microcode: updated from 0xe to 0x17
CPU: Intel(R) N100 (806.40-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0xb06e0  Family=0x6  Model=0xbe  Stepping=0

I reported the last two panics via the issue reporter; hopefully this is helping finding the issue.

Thanks,
Alex

3

23.1 Legacy Series / dhcpd running amok

« on: March 18, 2023, 03:42:59 pm »

Hello,

since a while sometimes my Opnsense firewall gets unresponsive and the only way to "fix" this is to make a hard reboot via powercycle.
The last time this happens I was by luck present (normally this happen e.g. over night etc).
I checked everything and the firewall had 100% CPU usage and used over 6,5 GB memory.
Reason for this where over 400(!) processes with this command:

Code: [Select]

/usr/local/sbin/dhcpd -6 -user dhcpd -group dhcpd -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid igb0
igb0 is my LAN interface btw.

Config content is:

Code: [Select]

option dhcp6.domain-search "localdomain";
option dhcp6.rapid-commit;

default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
one-lease-per-client true;
deny duplicates;
ping-check true;
update-conflict-detection false;
authoritative;

subnet6 IPv6_SUBNET::/64 {
  range6 IPv6_SUBNET::1000 IPv6_SUBNET::2000;
  option dhcp6.name-servers IPv6_SUBNET:227c:14ff:fea0:644e;
  prefix6 2003:ef:bf20:c080:: 2003:ef:bf20:c0f0::/62;
}

ddns-update-style none;
Did someone also experience this issue?

Thanks,
Alex

4

23.1 Legacy Series / [SOLVED] IPv6 with Telekom not working after upgrade

« on: January 18, 2023, 07:38:16 pm »

Hello,

after updating to 23.1.r1 the IPv6 setup with Telekom Deutschland is not working anymore.
I saw there a issue on Github https://github.com/opnsense/core/issues/6245 regarding the change to the new interface type 'PPPoEv6', but this change is not working for me.
When checking the interfaces for any hint, I saw this here:

Code: [Select]

inet6 fe80::227c:14ff:fea0:644e%pppoe0 prefixlen 64 scopeid 0x9
The prefix lenght is configured to 64, but for Telekom you normally need to request a /56 subnet.
As there is no configuration for this anymore (or I didn't found it), I think that cause the issue.

Thanks,
Alex

5

General Discussion / Help / Ideas needed to fix mirror config

« on: January 15, 2023, 09:34:04 pm »

Hello everyone,

I noticed in the last months some issues regarding my Opnsense mirror dns-root.de which is routed and cached via Cloudflare.
Error's like

Code: [Select]

Package checksum mismatch or missing packages which are stored on the disk but not cached by Cloudflare.  :'(
Unfortunatly out of personal reasons I was not able to deep dive into this problems in the last year, but now I want finally fix this issues and provide you a stable mirror.

My setup:

• Nginx docker container as webserver
• Rsync container triggered by a systemd timer
• Cloudflare to cache everything except defined files

The Cloudflare config is configured to

• Bypass changelog.txz, bogons.txz, meta.txz & packagesite.tgz
• Cache everything in the /releases folder for one month (installation iso's, so fine)
• Cache everything else for one month; but do not force this

From nginx side there are additional rules:

• Add "no-cache" header to changelog.txz, bogons.txz, meta.txz & packagesite.tgz
• Everything else cache 30 days

So basically both sides are configured nearly the same; only the iso's are forced to be cached for one month (which make sense because they are static).

My theory why the checksum error is happening is the following:

If a package is updated without a version change in the filename, the new checksum is part of the uncached system files, but as the file changed, the error appears.
When looking through the mirror folder I saw that the folder "Latest" in the package structure contains unversioned pkg-Files, only the "All"-folder contains all versioned pkg-files.

My ideas to solve this until now:

• Delete the Cloudflare cache when there are files changed by rsync (not so easy to implement with rsync)
• Not caching the "Latest"-folder (less caching rate, more traffic for server...)

Maybe some of you have a idea to solve this on a different way, or I'm missing something out of missing FreeBSD packaging knowledge 

Thanks a lot,
Alex



PS.
Thanks for 2 TB traffic per month; it is great to support you and the great project on this way 

6

22.1 Legacy Series / Kernel crash when starting a VNC connection

« on: February 13, 2022, 02:15:11 pm »

Hello,

I use for helping my parents etc. the VNC Viewer von Realvnc which connects via Realvnc to a VNC server on their computers.
After updating to 22.1, I can crash the Opnsense when trying to connect to one of their computers.

Here part of the crash-log:

Code: [Select]

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0x10
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80eb0dfd
stack pointer         = 0x28:0xfffffe000e1c06c0
frame pointer         = 0x28:0xfffffe000e1c07e0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (if_io_tqg_2)
trap number = 12
panic: page fault
cpuid = 2
time = 1644757931
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe000e1c0480
vpanic() at vpanic+0x17f/frame 0xfffffe000e1c04d0
panic() at panic+0x43/frame 0xfffffe000e1c0530
trap_fatal() at trap_fatal+0x385/frame 0xfffffe000e1c0590
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe000e1c05f0
calltrap() at calltrap+0x8/frame 0xfffffe000e1c05f0
--- trap 0xc, rip = 0xffffffff80eb0dfd, rsp = 0xfffffe000e1c06c0, rbp = 0xfffffe000e1c07e0 ---
ip6_forward() at ip6_forward+0x62d/frame 0xfffffe000e1c07e0
pf_refragment6() at pf_refragment6+0x164/frame 0xfffffe000e1c0830
pf_test6() at pf_test6+0xfdb/frame 0xfffffe000e1c09a0
pf_check6_out() at pf_check6_out+0x40/frame 0xfffffe000e1c09d0
pfil_run_hooks() at pfil_run_hooks+0x97/frame 0xfffffe000e1c0a10
ip6_tryforward() at ip6_tryforward+0x2ce/frame 0xfffffe000e1c0a90
ip6_input() at ip6_input+0x60f/frame 0xfffffe000e1c0b70
netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame 0xfffffe000e1c0bc0
ether_demux() at ether_demux+0x138/frame 0xfffffe000e1c0bf0
ether_nh_input() at ether_nh_input+0x355/frame 0xfffffe000e1c0c50
netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame 0xfffffe000e1c0ca0
ether_input() at ether_input+0x69/frame 0xfffffe000e1c0d00
iflib_rxeof() at iflib_rxeof+0xc27/frame 0xfffffe000e1c0e00
_task_fn_rx() at _task_fn_rx+0x72/frame 0xfffffe000e1c0e40
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x15d/frame 0xfffffe000e1c0ec0
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc2/frame 0xfffffe000e1c0ef0
fork_exit() at fork_exit+0x7e/frame 0xfffffe000e1c0f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe000e1c0f30
--- trap 0x80388000, rip = 0xffffffff80c2bcff, rsp = 0, rbp = 0x6 ---
mi_startup() at mi_startup+0xdf/frame 0x6
KDB: enter: panic
panic.txt0600001214202201653  7124 ustarrootwheelpage faultversion.txt0600007014202201653  7523 ustarrootwheelFreeBSD 13.0-STABLE stable/22.1-n248053-232cb14f501 SMP
I reported all three crashes via the reporting tool.
What can be the source of this crashes?

Thanks,

Alex

7

22.1 Legacy Series / Bad pkg performance while updating

« on: January 20, 2022, 08:29:44 pm »

Hello,

when updating via pkg from 21.7 to 22.1.r1 and now from 22.1.r1 to 22.1.r2 I had a very bad speed performance.
This happens, when pkg is try to fetch the base- and kernel txz; based on the Traffic overview in the web-gui, it runs with about 500 kbps.
Switching the mirror didn't help; a test download of such an archive was working in the expected speed.

Did someone of you had the same experience?

Thanks,

Alex

8

22.1 Legacy Series / [SOLVED] Strange Gateway hopping

« on: January 13, 2022, 03:15:43 pm »

Hello,

after upgrading to 22.1 R1 from 21.7 I saw a strange "gateway hopping".

Background:
To my firewall there are two internet connections connected:

• Telekom via PPPoE
• Vodafone via DHCP (ISP Provider in bridge mode)

In the past the gateways were configured that both gateways from Telekom (PPPoE IPv4 & DHCPv6 IPv6) have the priority of 253, the gateway for Vodafone have 254.
That was working as expected, as normally the Telekom connections were used mainly and only if there was a issue, the vodafone gateway were used.

Now after the switch to 22.1 I noticed that often the connection is switching between Telekom and Vodafone, which  cause issues with VOIP and other services which needs a stable connection.

The only tempfix now was to disable the vodafone interface; which is of course not ideal.
I know the "normal" way to handle a failover connection is to use the gateway group; but out of KISS reasons I tested the above solution and it worked for month without any major issue.

Was there a change in the routing behavior in 22.1?

Thanks,
Alex

9

22.1 Legacy Series / Upgrade to 22.1.r1 is not working

« on: January 12, 2022, 04:40:00 pm »

Hello,

maybe I'm to stupid to upgrade from 21.7.7 to 22.1.r1:

Code: [Select]

# opnsense-update -ur 22.1.r1
Fetching packages-22.1.r1-OpenSSL-amd64.tar: .. failed, no signature found
If I activate the verbosed log, I can see the issue:

Code: [Select]

# opnsense-update -V -ur 22.1.r1
+ [ '-r 22.1.r1' '=' -R ]
+ [ -n '-r 22.1.r1' ]
+ RELEASE=22.1.r1
+ [ -n '' ]
+ [ -n '' ]
+ [ ! -f /usr/local/etc/pkg/repos/OPNsense.conf ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -n '' ]
+ grep -q '^[[:space:]]*signature_type:[[:space:]]*"fingerprints"' /usr/local/etc/pkg/repos/OPNsense.conf
+ [ -n '' ]
+ [ -z '' ]
+ [ -n -u -o -n '' ]
+ DO_KERNEL=-k
+ DO_BASE=-b
+ DO_PKGS=-p
+ [ -n '' ]
+ [ -n '' ]
+ [ -z '' ]
+ [ -n -k -a -n '' -a -z -u ]
+ [ -n -b -a -n '' -a -z -u ]
+ [ -n -p -a -n '' -a -z -u ]
+ [ -n '' ]
+ [ -b '=' -B ]
+ [ -p '=' -P ]
+ [ -n '' ]
+ [ -p '=' -p -a -z -u ]
+ [ -n '' ]
+ FLAVOUR=Base
+ [ -n '' ]
+ [ -f /usr/local/bin/openssl ]
+ /usr/local/bin/openssl version
+ awk '{ print $1 }'
+ FLAVOUR=OpenSSL
+ DEVICE=''
+ [ -n '' ]
+ PACKAGESSET=packages-22.1.r1-OpenSSL-amd64.tar
+ KERNELSET=kernel-22.1.r1-amd64.txz
+ BASESET=base-22.1.r1-amd64.txz
+ mirror_abi
+ local 'DIR=\2'
+ [ -n '' ]
+ opnsense-verify -a
+ ABI=FreeBSD:12:amd64
+ [ -n '' ]
+ sed -n 's/^[[:space:]]*url:[[:space:]]*\"pkg\+\(.*\/${ABI}\/\)\([^\/]*\)\/.*/\1\2/p' /usr/local/etc/pkg/repos/OPNsense.conf
+ MIRROR='https://mirror.dns-root.de/opnsense/${ABI}/21.7'
+ [ -z 'https://mirror.dns-root.de/opnsense/${ABI}/21.7' ]
+ eval 'MIRROR=https://mirror.dns-root.de/opnsense/${ABI}/21.7'
+ MIRROR=https://mirror.dns-root.de/opnsense/FreeBSD:12:amd64/21.7
+ echo https://mirror.dns-root.de/opnsense/FreeBSD:12:amd64/21.7
+ MIRROR=https://mirror.dns-root.de/opnsense/FreeBSD:12:amd64/21.7/sets
+ [ -n '' ]
+ [ -z '' ]
+ [ 22.1.r1 '=' 21.7.7 -a -n -k ]
+ [ 22.1.r1 '=' 21.7.7 -a -n -b ]
+ [ -z -k-b-p ]
+ [ -p '=' -p ]
+ [ '-r 22.1.r1' '=' -R -a 22.1.r1 '=' unknown ]
+ [ -z '' -o -n -u ]
+ rm -f /usr/local/opnsense/version/core.lock
+ fetch_set packages-22.1.r1-OpenSSL-amd64.tar
+ STAGE1='opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/9672/packages-22.1.r1-OpenSSL-amd64.tar.sig https://mirror.dns-root.de/opnsense/FreeBSD:12:amd64/21.7/sets/packages-22.1.r1-OpenSSL-amd64.tar.sig'
+ STAGE2='opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/9672/packages-22.1.r1-OpenSSL-amd64.tar https://mirror.dns-root.de/opnsense/FreeBSD:12:amd64/21.7/sets/packages-22.1.r1-OpenSSL-amd64.tar'
+ STAGE3='opnsense-verify -q /var/cache/opnsense-update/9672/packages-22.1.r1-OpenSSL-amd64.tar'
+ [ -n '' ]
+ [ -n '' ]
+ echo -n 'Fetching packages-22.1.r1-OpenSSL-amd64.tar: .'
Fetching packages-22.1.r1-OpenSSL-amd64.tar: .+ mkdir -p /var/cache/opnsense-update/9672
+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/9672/packages-22.1.r1-OpenSSL-amd64.tar.sig https://mirror.dns-root.de/opnsense/FreeBSD:12:amd64/21.7/sets/packages-22.1.r1-OpenSSL-amd64.tar.sig
.+ exit_msg ' failed, no signature found'
+ [ -n ' failed, no signature found' ]
+ echo ' failed, no signature found'
 failed, no signature found
+ exit 1
It try to get the packages.tar from the 21.7 folder on the mirror; where of course the set is not stored.
What did I maybe missed?

Thanks a lot,
Alex

10

21.1 Legacy Series / subjectAltName is missing in new SSL cert

« on: May 14, 2021, 09:15:38 pm »

Hello,

I use the internal CA of the OpnSense Firewall to create SSL certs for internal devices.
In the past, that was working without any problem, but when I tried to issue a new cert today, the entered subjectAltName's are not part of the issued cert.

I douple checked all my settings and the issued cert, but it seems that something is going wrong here.

Can someone reproduce this issue or is able to help me in this topic?

Thanks,
Alex

11

20.7 Legacy Series / Specific IPs not pingable via IPv6

« on: August 01, 2020, 08:49:33 pm »

Hello,

after the upgrade to 20.7 I have a very special problem:
I normally use the IPv4 and IPv6 addresses of my external DNS resolvers as Health Endpoints for the Gateway monitoring.
After the upgrade, the IPv6 address of my resolver is not pingable anymore from the firewall.
The strange thing is: The IP is still accessable via ICMP from my client or any other computer, only the firewall is not able to reach the DNS server via IPv6.
DNS requests are no problem; only ICMP is affected.

Do anyone have a idea for this issue?

Thanks,

Alex

12

19.7 Legacy Series / Mirror is not able to update it's files

« on: August 23, 2019, 09:01:49 pm »

Good afternoon,

starting today afternoon around 18:40 UTC+2 my update script for the package mirror of Opnsense is not able anymore to sync with the main mirror.

Error message:

Code: [Select]

Aug 23 18:39:46 aigle docker[13800]: @ERROR: max connections (25) reached -- try again later
Aug 23 18:39:46 aigle docker[13800]: rsync error: error starting client-server protocol (code 5) at main.c(1657) [Receiver=3.1.3]
Aug 23 18:39:46 aigle systemd[1]: mirror.service: Main process exited, code=exited, status=5/NOTINSTALLED
Aug 23 18:39:46 aigle systemd[1]: mirror.service: Failed with result 'exit-code'.
It seems that the main server is somehow overloaded with connections or an another mirror is spawning to many connections.
Can someone of the Core team have a look to that?

Thanks,

Alex


PS. Sorry to spam the forum with that "internal" stuff of Mirror business...

13

German - Deutsch / Maybe Bug bei Unbound + OpenVPN

« on: August 16, 2017, 10:05:34 pm »

Hallo,

ich wieder mal mit lustigen VPN Problemen

Ich hab mich gerade ein wenig mit der DNS Auslösung über einen OpenVPN Tunnel gespielt und bin da über was drüber gefallen, was mir wenigstens etwas komisch vorkommt:
Wenn ich die Interfaces der OpenVPN Server als Listen-Interfaces des Unbound hinterlege, verwendet er nicht die Netze des VPN Servers in der Access-List, sondern nur das Interface (siehe Bild).

Quiz-Frage: ist das so gewollt oder sollte hier nicht das Netz verwendet werden (wie bei LAN)?

VG,

Alex

14

German - Deutsch / [GELÖST] Probleme mit AWS Site to Site VPN

« on: July 31, 2017, 07:04:54 pm »

Hallo zusammen,

wir kämpfen hier gerade mit einem kleinem Problem:

Ziel: Über die Firewall einen IPSec-Tunnel aufzubauen, der unser lokales Netz mit einer AWS VPC verbindet (also Site2Site).
Problem: Der Tunnel steht, aber es gehen keine Daten durch.

Wir haben schon mit dem AWS Support rumgemacht, kommen aber nicht hinter das Problem.
Im Endeffekt steht der Tunnel, aber es gehen keinerlei Daten von beiden Seiten drüber, weder ICMP noch SSH etc.
Auch die Byte-Zahl in der Tunnel-Statistik bleibt auf 0 stehen.

Ich hab die aktuellen Einstellungen von Phase 1 und 2 angehängt; diese wurden gemäß der Vorgaben von AWS hinterlegt (analog zu PFSense).

Hoffentlich weiß jemand von euch Rat.

Merci,

Alex

15

German - Deutsch / Komplexe Konfiguration IPv6 + OpenVPN

« on: October 17, 2016, 01:13:10 pm »

Hallo,

ich scheitere aktuell an folgender Konfiguration:

Wir haben hier eine Standleitung anliegen, die mit IPv4 und IPv6 IPs ausgestattet ist.
IPv4 wird aktuell schon verwendet und soll um IPv6 erweitert werden.
Idealerweise soll dafür ebenfalls der Datenverkehr nach außen über NATv6 laufen; macht uns die Verwaltung etc erheblich einfacher.
Intern soll DHCPv6 verwendet werden.

Außerdem soll in Zukunft eine OpenVPN-Verbindung von außen möglich sein; diese ist aber nicht dafür gedacht, ins interne Netz zu kommen, sondern nur, um über die Büro-IP nach außen zu kommen.
Dies ist notwendig, da manche externe Services nur von bestimmten IPs erreichbar sind.

Ich hab mich an dieser Konfiguration schon einmal gewagt, aber bin an der IPv6 Konfiguration gescheitert.
Maximal war es möglich, dass die Firewall ins Internet kam, aber kein Client mehr (sowohl über IPv4 als auch IPv6).

Kann vielleicht jemand mir da mal drüber sehen und mir vielleicht den ein oder anderen Tip geben, wie ich das so hinbekomme?

Vielen Dank,

Alex