VPN pfSense Fritte

eagle61

Ich möchte gerne IPSec für das Site2Site VPN nutzen, da es, wie ich finde, einfacher einzurichten ist

Bei IPSec bin ich draußen. Hab ich nie genutzt, denn die von der FritzBox unterstützten Algorithmen für die Verschlüsselung erscheinen mir deutlich zu schwach, also unsicher.

Als die FritzBoxen noch kein Wireguard unterstützt haben, habe ich einfach einen Raspbery Pi neben die FB gepackt und über diesen openVPN genutzt.

Inzwischen nutze ich nun Wireguard, das moderne und sichere Algorithmen für die Verschlüsselung nutzt und ebenfalls sehr einfach zu konfigureiren ist. Zudem ist Wireguard deutlich performanter als IPSec.

micneu

@eagle61 ich habe beides am laufen und mit der richtigen anleitung kann man alles einrichten, zu wireguard und pfsense & fritzbox kannst du in google eine gute Anleitung finden (die habe ich auch genutzt)

eagle61

@micneu said in VPN pfSense Fritte:

, zu wireguard und pfsense & fritzbox kannst du in google eine gute Anleitung finden (die habe ich auch genutzt)

richtig. Diese z.B. (https://v64.tech/t/anleitung-site2site-wireguard-verbindung-zwischen-pfsense-und-fritzbox/438) hilft sehr gut. Aber die Kommentare beachten. Die Standard MTU führt sonst zu Problemen.

EuroPC

Re: VPN pfSense Fritte

Anbei das versprochene Log.

Meine IP lautet übreigens (Dyndns via Synologyy.me)
WAN Uptime: 5d 02:01:44 93.zzz.xxx.yyy
und auf der Fritzbox Seite (via MyFritz) 217.xxx.yyy.zzz

Nun irritieren mich hier die Einträge
" Sep 4 08:44:01 charon 97256 09[NET] error writing to socket: Permission denied"
und
"Sep 4 08:44:31 charon 97256 14[CFG] vici client 156 requests: list-sas" hier fogt immer ein "disconnected"

und letztlich "Sep 4 08:46:46 charon 97256 06[IKE] <con1|61> giving up after 5 retransmits
Sep 4 08:46:46 charon 97256 06[IKE] <con1|61> establishing IKE_SA failed, peer not responding
Sep 4 08:46:46 charon 97256 06[IKE] <con1|61> IKE_SA con1[61] state change: CONNECTING => DESTROYING "

Also muss irgendettwas am IKE SA verkehrt sein.

Danke schonmal,
EuroPC

Hier das Logfile
Im Log- Lesen bin ich leider so gar nicht bewandert....

Sep 4 08:43:58 charon 97256 16[CFG] vici client 148 connected
Sep 4 08:43:58 charon 97256 13[CFG] vici client 148 registered for: list-sa
Sep 4 08:43:58 charon 97256 13[CFG] vici client 148 requests: list-sas
Sep 4 08:43:58 charon 97256 08[CFG] vici client 148 disconnected
Sep 4 08:44:01 charon 97256 13[CFG] vici client 149 connected
Sep 4 08:44:01 charon 97256 12[CFG] vici client 149 registered for: list-sa
Sep 4 08:44:01 charon 97256 13[CFG] vici client 149 requests: list-sas
Sep 4 08:44:01 charon 97256 08[CFG] vici client 149 disconnected
Sep 4 08:44:01 charon 97256 13[CFG] vici client 150 connected
Sep 4 08:44:01 charon 97256 15[CFG] vici client 150 registered for: control-log
Sep 4 08:44:01 charon 97256 08[CFG] vici client 150 requests: initiate
Sep 4 08:44:01 charon 97256 08[CFG] vici initiate CHILD_SA 'con1_1'
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> queueing ISAKMP_VENDOR task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> queueing ISAKMP_CERT_PRE task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> queueing AGGRESSIVE_MODE task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> queueing ISAKMP_CERT_POST task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> queueing ISAKMP_NATD task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> queueing QUICK_MODE task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> activating new tasks
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> activating ISAKMP_VENDOR task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> activating ISAKMP_CERT_PRE task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> activating AGGRESSIVE_MODE task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> activating ISAKMP_CERT_POST task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> activating ISAKMP_NATD task
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> sending XAuth vendor ID
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> sending DPD vendor ID
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> sending FRAGMENTATION vendor ID
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> sending NAT-T (RFC 3947) vendor ID
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> sending draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> initiating Aggressive Mode IKE_SA con1[61] to 217.195.149.213
Sep 4 08:44:01 charon 97256 13[IKE] <con1|61> IKE_SA con1[61] state change: CREATED => CONNECTING
Sep 4 08:44:01 charon 97256 13[CFG] <con1|61> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
Sep 4 08:44:01 charon 97256 13[ENC] <con1|61> generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
Sep 4 08:44:01 charon 97256 13[NET] <con1|61> sending packet: from 93.203.116.106[500] to 217.195.149.213[500] (398 bytes)
Sep 4 08:44:01 charon 97256 09[NET] error writing to socket: Permission denied
Sep 4 08:44:03 charon 97256 03[CFG] vici client 151 connected
Sep 4 08:44:03 charon 97256 13[CFG] vici client 151 registered for: list-sa
Sep 4 08:44:03 charon 97256 06[CFG] vici client 151 requests: list-sas
Sep 4 08:44:03 charon 97256 13[CFG] vici client 151 disconnected
Sep 4 08:44:05 charon 97256 06[IKE] <con1|61> sending retransmit 1 of request message ID 0, seq 1
Sep 4 08:44:05 charon 97256 06[NET] <con1|61> sending packet: from 93.203.116.106[500] to 217.195.149.213[500] (398 bytes)
Sep 4 08:44:05 charon 97256 09[NET] error writing to socket: Permission denied
Sep 4 08:44:06 charon 97256 06[CFG] vici client 150 disconnected
Sep 4 08:44:09 charon 97256 08[CFG] vici client 152 connected
Sep 4 08:44:09 charon 97256 08[CFG] vici client 152 registered for: list-sa
Sep 4 08:44:09 charon 97256 08[CFG] vici client 152 requests: list-sas
Sep 4 08:44:09 charon 97256 08[CFG] vici client 152 disconnected
Sep 4 08:44:12 charon 97256 03[IKE] <con1|61> sending retransmit 2 of request message ID 0, seq 1
Sep 4 08:44:12 charon 97256 03[NET] <con1|61> sending packet: from 93.203.116.106[500] to 217.195.149.213[500] (398 bytes)
Sep 4 08:44:12 charon 97256 09[NET] error writing to socket: Permission denied
Sep 4 08:44:14 charon 97256 03[CFG] vici client 153 connected
Sep 4 08:44:14 charon 97256 08[CFG] vici client 153 registered for: list-sa
Sep 4 08:44:14 charon 97256 08[CFG] vici client 153 requests: list-sas
Sep 4 08:44:14 charon 97256 03[CFG] vici client 153 disconnected
Sep 4 08:44:20 charon 97256 04[CFG] vici client 154 connected
Sep 4 08:44:20 charon 97256 03[CFG] vici client 154 registered for: list-sa
Sep 4 08:44:20 charon 97256 03[CFG] vici client 154 requests: list-sas
Sep 4 08:44:20 charon 97256 04[CFG] vici client 154 disconnected
Sep 4 08:44:25 charon 97256 03[IKE] <con1|61> sending retransmit 3 of request message ID 0, seq 1
Sep 4 08:44:25 charon 97256 03[NET] <con1|61> sending packet: from 93.203.116.106[500] to 217.195.149.213[500] (398 bytes)
Sep 4 08:44:25 charon 97256 09[NET] error writing to socket: Permission denied
Sep 4 08:44:25 charon 97256 04[CFG] vici client 155 connected
Sep 4 08:44:25 charon 97256 10[CFG] vici client 155 registered for: list-sa
Sep 4 08:44:25 charon 97256 10[CFG] vici client 155 requests: list-sas
Sep 4 08:44:25 charon 97256 10[CFG] vici client 155 disconnected
Sep 4 08:44:31 charon 97256 10[CFG] vici client 156 connected
Sep 4 08:44:31 charon 97256 03[CFG] vici client 156 registered for: list-sa
Sep 4 08:44:31 charon 97256 14[CFG] vici client 156 requests: list-sas
Sep 4 08:44:31 charon 97256 03[CFG] vici client 156 disconnected
Sep 4 08:44:36 charon 97256 14[CFG] vici client 157 connected
Sep 4 08:44:36 charon 97256 03[CFG] vici client 157 registered for: list-sa
Sep 4 08:44:36 charon 97256 03[CFG] vici client 157 requests: list-sas
Sep 4 08:44:36 charon 97256 03[CFG] vici client 157 disconnected
Sep 4 08:44:42 charon 97256 03[CFG] vici client 158 connected
Sep 4 08:44:42 charon 97256 05[CFG] vici client 158 registered for: list-sa
Sep 4 08:44:42 charon 97256 03[CFG] vici client 158 requests: list-sas
Sep 4 08:44:42 charon 97256 05[CFG] vici client 158 disconnected
Sep 4 08:44:47 charon 97256 03[CFG] vici client 159 connected
Sep 4 08:44:47 charon 97256 03[CFG] vici client 159 registered for: list-sa
Sep 4 08:44:47 charon 97256 03[CFG] vici client 159 requests: list-sas
Sep 4 08:44:47 charon 97256 11[CFG] vici client 159 disconnected
Sep 4 08:44:48 charon 97256 03[IKE] <con1|61> sending retransmit 4 of request message ID 0, seq 1
Sep 4 08:44:48 charon 97256 03[NET] <con1|61> sending packet: from 93.203.116.106[500] to 217.195.149.213[500] (398 bytes)
Sep 4 08:44:48 charon 97256 09[NET] error writing to socket: Permission denied
Sep 4 08:44:52 charon 97256 03[CFG] vici client 160 connected
Sep 4 08:44:52 charon 97256 11[CFG] vici client 160 registered for: list-sa
Sep 4 08:44:52 charon 97256 03[CFG] vici client 160 requests: list-sas
Sep 4 08:44:52 charon 97256 16[CFG] vici client 160 disconnected
Sep 4 08:44:58 charon 97256 03[CFG] vici client 161 connected
Sep 4 08:44:58 charon 97256 16[CFG] vici client 161 registered for: list-sa
Sep 4 08:44:58 charon 97256 16[CFG] vici client 161 requests: list-sas
Sep 4 08:44:58 charon 97256 03[CFG] vici client 161 disconnected
Sep 4 08:45:03 charon 97256 12[CFG] vici client 162 connected
Sep 4 08:45:03 charon 97256 03[CFG] vici client 162 registered for: list-sa
Sep 4 08:45:03 charon 97256 03[CFG] vici client 162 requests: list-sas
Sep 4 08:45:03 charon 97256 12[CFG] vici client 162 disconnected
Sep 4 08:45:09 charon 97256 12[CFG] vici client 163 connected
Sep 4 08:45:09 charon 97256 15[CFG] vici client 163 registered for: list-sa
Sep 4 08:45:09 charon 97256 15[CFG] vici client 163 requests: list-sas
Sep 4 08:45:09 charon 97256 15[CFG] vici client 163 disconnected
Sep 4 08:45:14 charon 97256 12[CFG] vici client 164 connected
Sep 4 08:45:14 charon 97256 15[CFG] vici client 164 registered for: list-sa
Sep 4 08:45:14 charon 97256 06[CFG] vici client 164 requests: list-sas
Sep 4 08:45:14 charon 97256 15[CFG] vici client 164 disconnected
Sep 4 08:45:20 charon 97256 15[CFG] vici client 165 connected
Sep 4 08:45:20 charon 97256 06[CFG] vici client 165 registered for: list-sa
Sep 4 08:45:20 charon 97256 06[CFG] vici client 165 requests: list-sas
Sep 4 08:45:20 charon 97256 06[CFG] vici client 165 disconnected
Sep 4 08:45:25 charon 97256 06[CFG] vici client 166 connected
Sep 4 08:45:25 charon 97256 12[CFG] vici client 166 registered for: list-sa
Sep 4 08:45:25 charon 97256 12[CFG] vici client 166 requests: list-sas
Sep 4 08:45:25 charon 97256 06[CFG] vici client 166 disconnected
Sep 4 08:45:30 charon 97256 12[IKE] <con1|61> sending retransmit 5 of request message ID 0, seq 1
Sep 4 08:45:30 charon 97256 12[NET] <con1|61> sending packet: from 93.203.116.106[500] to 217.195.149.213[500] (398 bytes)
Sep 4 08:45:30 charon 97256 09[NET] error writing to socket: Permission denied
Sep 4 08:45:31 charon 97256 08[CFG] vici client 167 connected
Sep 4 08:45:31 charon 97256 12[CFG] vici client 167 registered for: list-sa
Sep 4 08:45:31 charon 97256 12[CFG] vici client 167 requests: list-sas
Sep 4 08:45:31 charon 97256 08[CFG] vici client 167 disconnected
Sep 4 08:45:36 charon 97256 08[CFG] vici client 168 connected
Sep 4 08:45:36 charon 97256 04[CFG] vici client 168 registered for: list-sa
Sep 4 08:45:36 charon 97256 08[CFG] vici client 168 requests: list-sas
Sep 4 08:45:36 charon 97256 10[CFG] vici client 168 disconnected
Sep 4 08:45:42 charon 97256 10[CFG] vici client 169 connected
Sep 4 08:45:42 charon 97256 08[CFG] vici client 169 registered for: list-sa
Sep 4 08:45:42 charon 97256 10[CFG] vici client 169 requests: list-sas
Sep 4 08:45:42 charon 97256 08[CFG] vici client 169 disconnected
Sep 4 08:45:47 charon 97256 08[CFG] vici client 170 connected
Sep 4 08:45:47 charon 97256 10[CFG] vici client 170 registered for: list-sa
Sep 4 08:45:47 charon 97256 14[CFG] vici client 170 requests: list-sas
Sep 4 08:45:47 charon 97256 10[CFG] vici client 170 disconnected
Sep 4 08:45:52 charon 97256 08[CFG] vici client 171 connected
Sep 4 08:45:52 charon 97256 10[CFG] vici client 171 registered for: list-sa
Sep 4 08:45:52 charon 97256 10[CFG] vici client 171 requests: list-sas
Sep 4 08:45:52 charon 97256 08[CFG] vici client 171 disconnected
Sep 4 08:45:58 charon 97256 05[CFG] vici client 172 connected
Sep 4 08:45:58 charon 97256 08[CFG] vici client 172 registered for: list-sa
Sep 4 08:45:58 charon 97256 08[CFG] vici client 172 requests: list-sas
Sep 4 08:45:58 charon 97256 05[CFG] vici client 172 disconnected
Sep 4 08:46:03 charon 97256 08[CFG] vici client 173 connected
Sep 4 08:46:03 charon 97256 05[CFG] vici client 173 registered for: list-sa
Sep 4 08:46:03 charon 97256 11[CFG] vici client 173 requests: list-sas
Sep 4 08:46:03 charon 97256 05[CFG] vici client 173 disconnected
Sep 4 08:46:09 charon 97256 11[CFG] vici client 174 connected
Sep 4 08:46:09 charon 97256 11[CFG] vici client 174 registered for: list-sa
Sep 4 08:46:09 charon 97256 11[CFG] vici client 174 requests: list-sas
Sep 4 08:46:09 charon 97256 16[CFG] vici client 174 disconnected
Sep 4 08:46:14 charon 97256 11[CFG] vici client 175 connected
Sep 4 08:46:14 charon 97256 16[CFG] vici client 175 registered for: list-sa
Sep 4 08:46:14 charon 97256 16[CFG] vici client 175 requests: list-sas
Sep 4 08:46:14 charon 97256 11[CFG] vici client 175 disconnected
Sep 4 08:46:20 charon 97256 11[CFG] vici client 176 connected
Sep 4 08:46:20 charon 97256 03[CFG] vici client 176 registered for: list-sa
Sep 4 08:46:20 charon 97256 11[CFG] vici client 176 requests: list-sas
Sep 4 08:46:20 charon 97256 03[CFG] vici client 176 disconnected
Sep 4 08:46:25 charon 97256 03[CFG] vici client 177 connected
Sep 4 08:46:25 charon 97256 13[CFG] vici client 177 registered for: list-sa
Sep 4 08:46:25 charon 97256 13[CFG] vici client 177 requests: list-sas
Sep 4 08:46:25 charon 97256 03[CFG] vici client 177 disconnected
Sep 4 08:46:30 charon 97256 03[CFG] vici client 178 connected
Sep 4 08:46:30 charon 97256 13[CFG] vici client 178 registered for: list-sa
Sep 4 08:46:30 charon 97256 15[CFG] vici client 178 requests: list-sas
Sep 4 08:46:30 charon 97256 03[CFG] vici client 178 disconnected
Sep 4 08:46:36 charon 97256 03[CFG] vici client 179 connected
Sep 4 08:46:36 charon 97256 15[CFG] vici client 179 registered for: list-sa
Sep 4 08:46:36 charon 97256 15[CFG] vici client 179 requests: list-sas
Sep 4 08:46:36 charon 97256 06[CFG] vici client 179 disconnected
Sep 4 08:46:41 charon 97256 06[CFG] vici client 180 connected
Sep 4 08:46:41 charon 97256 15[CFG] vici client 180 registered for: list-sa
Sep 4 08:46:41 charon 97256 06[CFG] vici client 180 requests: list-sas
Sep 4 08:46:41 charon 97256 15[CFG] vici client 180 disconnected
Sep 4 08:46:46 charon 97256 06[IKE] <con1|61> giving up after 5 retransmits
Sep 4 08:46:46 charon 97256 06[IKE] <con1|61> establishing IKE_SA failed, peer not responding
Sep 4 08:46:46 charon 97256 06[IKE] <con1|61> IKE_SA con1[61] state change: CONNECTING => DESTROYING
Sep 4 08:46:47 charon 97256 06[CFG] vici client 181 connected
Sep 4 08:46:47 charon 97256 12[CFG] vici client 181 registered for: list-sa
Sep 4 08:46:47 charon 97256 12[CFG] vici client 181 requests: list-sas
Sep 4 08:46:47 charon 97256 12[CFG] vici client 181 disconnected
Sep 4 08:46:52 charon 97256 04[CFG] vici client 182 connected
Sep 4 08:46:52 charon 97256 12[CFG] vici client 182 registered for: list-sa
Sep 4 08:46:52 charon 97256 12[CFG] vici client 182 requests: list-sas
Sep 4 08:46:52 charon 97256 04[CFG] vici client 182 disconnected
Sep 4 08:46:58 charon 97256 14[CFG] vici client 183 connected
Sep 4 08:46:58 charon 97256 04[CFG] vici client 183 registered for: list-sa
Sep 4 08:46:58 charon 97256 14[CFG] vici client 183 requests: list-sas
Sep 4 08:46:58 charon 97256 04[CFG] vici client 183 disconnected
Sep 4 08:47:03 charon 97256 14[CFG] vici client 184 connected
Sep 4 08:47:03 charon 97256 04[CFG] vici client 184 registered for: list-sa
Sep 4 08:47:03 charon 97256 10[CFG] vici client 184 requests: list-sas
Sep 4 08:47:03 charon 97256 10[CFG] vici client 184 disconnected
Sep 4 08:47:09 charon 97256 10[CFG] vici client 185 connected
Sep 4 08:47:09 charon 97256 04[CFG] vici client 185 registered for: list-sa
Sep 4 08:47:09 charon 97256 08[CFG] vici client 185 requests: list-sas
Sep 4 08:47:09 charon 97256 04[CFG] vici client 185 disconnected
Sep 4 08:47:14 charon 97256 04[CFG] vici client 186 connected
Sep 4 08:47:14 charon 97256 08[CFG] vici client 186 registered for: list-sa
Sep 4 08:47:14 charon 97256 08[CFG] vici client 186 requests: list-sas
Sep 4 08:47:14 charon 97256 04[CFG] vici client 186 disconnected
Sep 4 08:47:20 charon 97256 04[CFG] vici client 187 connected
Sep 4 08:47:20 charon 97256 05[CFG] vici client 187 registered for: list-sa
Sep 4 08:47:20 charon 97256 05[CFG] vici client 187 requests: list-sas
Sep 4 08:47:20 charon 97256 05[CFG] vici client 187 disconnected

EuroPC

@micneu Danke. Ich fülle das mal aus und melde mich.

Gruß,
EuroPC

NOCling

Danke Mic für das File, aber 2024 bitte dh15 eintragen wenn es aktuelle AVM Kisten sind.

Das AES256 ist mit DH15 auch 2024 noch sicher, da hier im Main Mode gefahren wird also Isakamp für den Keyexchange verwendet wird.
Dazu einen schönen langen generierten PSK und gut ist.

EuroPC

@EuroPC said in VPN pfSense Fritte:

@eagle61 wo Du es schreibst, das hatte ich tatsächlich vergessen. Ich möchte gerne IPSec für das Site2Site VPN nutzen, da es, wie ich finde, einfacher einzurichten ist.

Was Firewall Regeln angeht hoffte ich,. dass sich die pfSense diese selbst generiert.

Nun habe ich also unter IPSec eingetragen:
Protocol Source Port Destination Port Gateway Queue Schedule Description
ipv4 * * * * * none IPSec Any

unter Advanced habe ich keine Änderungen, also das Default Gateway.

Gruß EuroPC

Allerdings habe ich unter Firewall --> NAT eingestellt bzw defaulkt gelassen.

"Automatic outbound NAT rule generation.
(IPsec passthrough included)"

Daher habe ich erwartet, dass die pfSense aich selbst drum kümmert.

NOCling

IPsec Regel habe ich unter Floating mit UDP/500 und UDP/4500 mit Quelle Any und Ziel this Firewall angelegt.
Nutze aber auch den NAT Hybrid mode.

NOCling

Wie sind die Tunnel Parameter auf pf Seite?

Die Fritz versucht mit aggressive Mode IKEv1 rein zu verbinden.
Für Main musst du das Config File in der FritzBox raus ziehen mit dem Editor, anpassen und wieder rein spielen.

Die AVM Boxen brauchen:
P1: AES CBC 256, SHA 512, DH2 und DH 14/15
P2: ARS CBC 256, SHA 512, DH 14/15

Also zwei Phase 1 Einträge anlegen, die erste Aushandlung ist mit DH2, der Tunnel geht dann aber auf 14/15 hoch. Hier muss dann in beiden Phasen der gleich Wert stehen, also 14 oder 15.

JeGr

Moin,

@EuroPC said in VPN pfSense Fritte:

Allerdings habe ich unter Firewall --> NAT eingestellt bzw defaulkt gelassen.

"Automatic outbound NAT rule generation.
(IPsec passthrough included)"

Daher habe ich erwartet, dass die pfSense aich selbst drum kümmert.

Firewall Regeln sind doch erstmal vollkommen Schnuppe. Wenn IPsec verwendet wird, werden auch automatisch dafür eingehende Regeln geschaltet. Regeln für den Traffic dann später ÜBER den Tunnel sind ne eigene Nummer aber zum Verbindungsaufbau absolut irrelevant

IPv6 habe ich auf beiden Seiten. IPv4 wäre schöner, die Adressen kann ich mir wenigstens merken ;-)

Irgendwas merken können ist bei IP generell irrelevant, dafür gibts DNS ;) Und wenn du schon mit DSlite oder CGNAT rumkrebst, wirst du nicht drumrum kommen das zu nutzen, was beide können.

@EuroPC said in VPN pfSense Fritte:

Anbei das versprochene Log.

Sep 4 08:46:46 charon 97256 06[IKE] <con1|61> giving up after 5 retransmits
Sep 4 08:46:46 charon 97256 06[IKE] <con1|61> establishing IKE_SA failed, peer not responding
Sep 4 08:46:46 charon 97256 06[IKE] <con1|61> IKE_SA con1[61] state change: CONNECTING => DESTROYING

Da steht das Problem. Peer not responding. pfSense Seite versucht den Aufbau, kommt aber nix zurück, die Fritte antwortet nicht.
Zum Debuggen stellt man am Besten eine Seite auf Responder only (die pfSense) indem man das bei der P1 in den Child SA Start Actions auswählt. Dann baut sie nicht auf, sondern wartet nur dass sich die Fritte melden. Dann startet mans auf der Fritte und schaut nochmal ins Log um zu sehen ob was ankommt.

Dein Problem wird erstmal sein, dass die sich überhaupt finden, wahrscheinlich gegenseitig mit dyndns Namen? Zusätzlich dann auch die ID auf beiden Seiten, die sollte entweder fest gesetzt werden oder via DNS ebenfalls gesetzt, denn mit sowas wie "Peer ID: gateway IP" oder "my IP" werden bei dynamischen IPs und ggf. auch IP6 die beiden Seiten nicht glücklich werden, wenn sich ständig was ändert.

"Einfach" ist IPsec aber nicht, vor allem nicht bei zwei unterschiedlichen Geräten von denen auch noch eins mit Hinterwäldler-Einstellungen rumkrebst und sich nicht ordentlich konfigurieren lässt. Wenn selbst der AVM Support dir am Telefon noch was vom alten AVM VPN Server von damals vorflötet, der ja so flexibel war, dann weiß man, was die Stunde geschlagen hat ;)

Cheers.

EuroPC

@JeGr
Erstmal Entschuldigung fürs späte Antworten. Ich bin derzeit selten zu Hause.

„ Dein Problem wird erstmal sein, dass die sich überhaupt finden, wahrscheinlich gegenseitig mit dyndns Namen?“

Ja, das stelle ich auch gerade fest. Die DynDNS Adresse ist via Synology.me eingegeben. Wenn ich nen Ping sende, gibt es nen Timeout.

Vielleicht ist IPSec zur Fritte doch nicht so super, wie ich in Erinnerung habe. Ein anderer Post hier hat auf WireGuard zwischen Fritte und PfSense verwiesen. Das wäre vielleicht ein probater Ersatz.

EuroPC

NOCling

Aber auch dann muss die DynDNS Adresse passen.

eagle61

@EuroPC said in VPN pfSense Fritte:

Ja, das stelle ich auch gerade fest. Die DynDNS Adresse ist via Synology.me eingegeben. Wenn ich nen Ping sende, gibt es nen Timeout

Ich würde sagen, dass du sogar noch einen Schritt weiter vorn anfangen musst. Nämlich dabei herauszufinden ob eine oder gar beide der VPN-Gegenstellen, also die FritzBox oder die pfsense an einem DS-Lite oder CGNAT-Anschluss hängen. Weder bei DS-Lite oder CGNAT hast du dann ja noch öffentlich erreichbare exklusive IPv4-Adressen.

Trifft das nur auf eine der VPN-Gegenstellen zu, ist das nicht so schlimm, dann muss halt die VPN-Gegenstelle die Verbindung initieren, die am DS-Lite oder CGNAT-Anschluss hängt. Haben beide DS-Lite oder CGNAT wird jeder Verbindungsaufbau via IPv4 scheitern. Dann wird das nur per IPv6 möglich sein oder nur mittels eines vServers mit IPv4-Adresse der dann für beide Seiten als Gateway dient.

Einen CGNAT-Anschluss erkennst du an der IPv4-Adresse. ist die zwischen 100.64.0.0. und 100.127.255.255 dann ist es CGNAT. Provider die DS-Lite bieten nutzen ein AFTR-Gateway.

EuroPC

@eagle61 Ich habe gerade getestet über meine Synology.me Dyndns- Adresse: Timeout
bzw. ipv64.net auch hier ein Timeout
Die IP Adresse lautet 93.xxx.yy.zzz (Telekom)
Demnach kein cgNAT.

Die MyFritz- Adresse funktioniert hingegen tadellos. IP 217.xxx.yyy.zzz (Greenfiber)
Die Synology.me Adresse funktioniert ebenfalls.

Je zwei DynDNS- Adressen habe ich, da ich erst annahm, dass der Synology- Dienst vielleicht spinnt.

Ob ich auf einer Seite CGNAT habe, teste ich morgen mal.

EuroPC

eagle61

@EuroPC said in VPN pfSense Fritte:

Ob ich auf einer Seite CGNAT habe, teste ich morgen mal.

Nö, hast Du eher nicht, denn dann sollte die IPv4-Adresse im Bereich zwischen 100.64,0.0 bis 100.127.255.255 liegen

Am Anschluss der Telekom sollte sowieso weder DS-Lite noch CGNAT anliegeb. Wäre mir ganz neu dass die eins von beidem Nutzen. Zu dem Greenfiber kann ich nichts sagen. Dr. g00gle verrät einem dazu auch nichts. CGNAT wird es aber nicht sein, wegen der IP-Adresse, Wenn dann DS-Lite. Falls das so sein sollte, wirf einfach eine Blick ins Logfile der FritzBox am Greenfiber-Anschluss. Dort müsste sich dann ein EIntrag mit AFTR finden lassen.

Stimmen denn auf Seite der pfsense die DynDNS-Adresse und die tatsächliche IPv4-Adresse überein? Also mal den Status / Interfaces / WAN mit dem was ein ping auf die DynDNS-Adresse ausspuckt vergleichen.

Zudem die pfsense beantwortet standardmäßig keine pings.
Damit die das tut muss unter Firewall / Rules / WAN natürlich zunächst eine passende Regel (ICMP) hinzugefügt werden und dann natürlich auch einen für das VPN.

EuroPC

@eagle61
Danke für die Info.

Der Ping auf die IP in Status/interfaces/wan verlief erfolgreich.
Ebenso der auf meine Synology.me Adresse (ohne dass ich an den FW Regeln etwas ändern musste).
Der auf ipv64.net verwies auf eine falsche IP.
Insofern passt das alles. Es scheint also auch daran zu liegen, dass die Dyndns Adressen zu selten aktualisiert werden.

Den Eintrag zu DSLite sehe ich nicht. Weder in den Logs noch in der Übersicht. Damit habe ich es wohl nicht. Auch habe ich IPSec Verbindungen zu anderen Fritten laufen.
Ich versuche mal die Sense in den „Empfängermodus“ zu schalten, wie @JeGr es vorgeschlagen hat. Evtl sehe ich dann etwas in den Logs.
Bisher scheint jetzt ein“List- SAS Problem vorzuliegen.

Immerhin funktioniert die Dyndns Adresse jetzt. .)

Gruß, EuroPC

NOCling

DynDNs ist die Basis, stimmen die nicht kannst du alles vergessen, ICMP und jegliches VPN.
Eine Regel auf WAN die einem Alias ICMP Echo erlaubt ist ein guter Start.
Dann können alle Tunnelendpunkte hier schon mal die Strecke hin testen, ist ja nicht selten auch mal ein Peering Problem dazwischen.

Und DynDNS sollte am besten auf der Kiste laufen die direkt am WAN mit ihrer public IP hängt.
Die AVM Kisten haben da mit Myfritz einen super Dienst gleich mit dabei.

Stimmt das DynDNS Zeugs laufen die IPsec Tunnel zu den AVM Boxen dann stabil, hat man einmal den dreh raus.
Haben hier 3 Tunnel zu einer 7590AX, einer 7590 und einer 7362SL, ja selbst mit dem Dino läuft das über Wochen stabil.

eagle61

@EuroPC said in VPN pfSense Fritte:

Der Ping auf die IP in Status/interfaces/wan verlief erfolgreich.
Ebenso der auf meine Synology.me Adresse (ohne dass ich an den FW Regeln etwas ändern musste).
Der auf ipv64.net verwies auf eine falsche IP.

Um IPSec erst einmal grundsätzlic ans Laufen zu bekommen kannst du statt der DynDNS-Adresse auch die aktuellen IPv4-Adressen beider Gegenstellen verwenden.
SO eine Verbindung wird dann zwar nur bis zur nächsten Zwangstrennung seitens Telekom oder Greenwire, oder wie auch immer der Glasfaseranbiter n och mal heißen mag, halten, aber wenn es mit den IP-Adressen klappt, dann bist du schon mal sehr viel weiter und kannst dich auf die korrekte Zuweisung und aktualisierung der DynDNS-Adressen konzentrieren.

Alternative ist erst einmal dafür zu sorgen, dass die DynDNS-Adressen zuverlässig und sicher korrekt zugewiesne und aktualiesiert werden. Erst wenn das klappt, dann mit dem VPN weitermachen.

JeGr

@EuroPC said in VPN pfSense Fritte:

Ja, das stelle ich auch gerade fest. Die DynDNS Adresse ist via Synology.me eingegeben. Wenn ich nen Ping sende, gibt es nen Timeout.

Hat nicht unbedingt was zu heißen, die Geräte müssen ja nicht default auf nen Ping antworten. Aber wenn die die entsprechenden Ports/Protokolle gar nicht bekommen, klappt natürlich nix.

@NOCling said in VPN pfSense Fritte:

Aber auch dann muss die DynDNS Adresse passen.

Wenn beide Seiten dynamisch sind, kann Wireguard auch direkt in die Hose gehen, dann kanns sein, dass die sich nach beidseitigem IP change gar nicht mehr finden, weil sie die DynDNS nicht frisch einlesen.

@EuroPC said in VPN pfSense Fritte:

Die IP Adresse lautet 93.xxx.yy.zzz (Telekom)
Demnach kein cgNAT.

Das ist die Adresse die du zurückbekommst von "extern" also unter der du Abfragen machst. Das sagt aber nichts drüber aus, ob du die via CGNAT bekommst oder nicht. Kein externer Dienst meldet dir 100.64.x zurück, das wird nicht geroutet.

Wichtig ist, dass beide Seiten sich jeweils gegenseitig über ne DNS Adresse sehen, von wem oder was die ist, ist egal, aber sie muss stimmen, aktuell sein und das Gerät dahinter muss udp/500, 4500 und esp als Protokoll abbekommen, sonst gibts kein IPsec. Wenn die pfSense Seite bspw. hinter nem anderen Gerät hängt muss man prüfen, ob das das z.B. wegfrisst. Hatten wir auch schon, dass da ein Zyxel Modem/Router davor saß, der einfach kackfrech alles IPsec mäßige weggefressen hat.

Cheers

eagle61

@JeGr said in VPN pfSense Fritte:

Wenn beide Seiten dynamisch sind, kann Wireguard auch direkt in die Hose gehen, dann kanns sein, dass die sich nach beidseitigem IP change gar nicht mehr finden, weil sie die DynDNS nicht frisch einlesen

Ich finde es auch nervig, dass viele ISP in DE bei Privatkundentarifen noch immer die Zwangstrennung machen und durch diese Zwangstrennung immer eine neue IPv4-Adresse und ein neuer IPv6-Präfix zugewiesen werden. Aber das lässt sich ganz gut managen.
Ich bin mit meiner pfsense auch bei so einem ISP. Jede Nacht Zwangstrennung. Da ich vor der pfsense ein Modem habe und daher PPPoE verwende, kann ich das aber via /var/etc/pppoe_restart_pppoe0 als Cronjob steuerm, also wenigstens auf die Minute genau die Zeit bestimmen zu der das passiert.
Als DynDNS-Client nutze ich seitens der pf den customv4 und customv6. Maximal zwei Minuten nach dem PPPoE-Restart übermitteln der die neue IPv4 und IPv6 an den DynDNS-Provider. Das klappt seit Monaten 100% zuverlässig, wie die Logs belegen.
Als VPN zwischen pfsense und FritzBoxen nutze ich nur noch Wireguard. Auch diese sind beim Provider mit Zwangstrennung. Die nutzen den MyFritz-DnyDNS-Dienst. Auch der liefert zuverlässig nach der Zwangstrennung die korrekten Ipv4- und IPv6-Adressen.
Hinter einer der Fritten hab ich noch einen Rapsberry PI. Der u.a. den Tunnel überwacht. Schickt alle 15 Minuten 5 pings durch den Tunnel und wenn die Pings nicht durchgehen bekomme ich von dem Pi ne eMail. Kam in drei Monaten drei oder vier mal vor, dass diese eMail kam. Sobald der Tunnel dann wieder steht, kommt noch eine Mail. Weg war der Tunnel nie länger als diese 15 Minuten.