IPSEC Tunnel Online, maar geen verkeer

[Rolfie]

Ik heb een vaag probleem. Ik heb een IPSEC tunnel tussen 2 pfsense firewalls. De IPSEC tunnel komt in de lucht, echter vind er geen dataverkeer tussen beide firewalls, of zoals ik het zie, ik ontvang geen verkeer op Firewall 1.

En ik kan maar niet vinden waarom.

Locatie 1 / Firewall 1 LAN subnet: 172.16.28.0/24.
Locatie 2 / Firewall 2 LAN subnet: 192.168.178.0/24. Deze draait op een ESXi machine, virtueel.

Als ik de IPSEC configuratie bekijk, dan zie ik netjes dat de tunnel gemaakt wordt, echter Firewall 1 ontvangt nooit verkeer terwijl firewall 2 wel aangeeft dat er data wordt verzonden.



De SADs laat het zelfde effect zien.





Firewall 1 configuratie:

code:

# This file is automatically generated. Do not edit
config setup
        uniqueids = yes

conn bypasslan
        leftsubnet = 172.16.28.0/24
        rightsubnet = 172.16.28.0/24
        authby = never
        type = passthrough
        auto = route

conn con2000
        fragmentation = yes
        keyexchange = ikev2
        reauth = yes
        forceencaps = no
        mobike = no

        rekey = yes
        installpolicy = yes
        type = tunnel
        dpdaction = restart
        dpddelay = 10s
        dpdtimeout = 60s
        auto = route
        left = X.Y.Z.155
        right = A.B.C.179
        leftid = X.Y.Z.155
        ikelifetime = 28800s
        lifetime = 3600s
        ike = aes128-sha1-modp1024!
        esp = aes128-sha1-modp1024!
        leftauth = psk
        rightauth = psk
        rightid = A.B.C.179
        rightsubnet = 192.168.178.0/24
        leftsubnet = 172.16.28.0/24

Firewall 2 configuratie:

code:

# This file is automatically generated. Do not edit
config setup
        uniqueids = yes

conn bypasslan
        leftsubnet = 192.168.178.0/24
        rightsubnet = 192.168.178.0/24
        authby = never
        type = passthrough
        auto = route

conn con3000
        fragmentation = yes
        keyexchange = ikev2
        reauth = yes
        forceencaps = no
        mobike = no

        rekey = yes
        installpolicy = yes
        type = tunnel
        dpdaction = restart
        dpddelay = 10s
        dpdtimeout = 60s
        auto = route
        left = A.B.C.179
        right = X.Y.Z.155
        leftid = A.B.C.179
        ikelifetime = 28800s
        lifetime = 3600s
        ike = aes128-sha1-modp1024!
        esp = aes128-sha1-modp1024!
        leftauth = psk
        rightauth = psk
        rightid = X.Y.Z.155
        rightsubnet = 172.16.28.0/24
        leftsubnet = 192.168.178.0/24

De tunnel heeft ooit in het verleden gewerkt. Maar ik heb de tunnel ooit verwijderd en probeer deze nu opnieuw te maken.
Firewall 1 heeft altijd meerdere werkende IPSEC tunnels gehad, dus ik verwacht dat daar niets vreemds zit.

Ondertussen heb ik al uren zitten troubleshooten in logfiles, IPSEC tunnel meerdere keren opnieuw gemaakt. Firewalls gereboot….

[ik222]

Je hebt ook firewall regels aangemaakt om het verkeer toe te staan?

[Rolfie]

ik222 schreef op maandag 5 augustus 2019 @ 21:41:
Je hebt ook firewall regels aangemaakt om het verkeer toe te staan?

Had ik inderdaad niet vermeld, maar de rules zijn er. Ik zie ook het verkeer in de filtering voorbij komen.

Ik ben gisteren echter wel verder gekomen. Het blijkt dat de Internet provider het verkeer NAT richting ons, wat niet de bedoeling zou moeten is.
Dit zou wel eens de problemen kunnen verklaren. Nog wel raar dat de tunnel op komt, wat ik namelijk niet zou verwachten, immers de tunnel komt in eens van hele andere IP's af.

Dit verklaard ook meteen diverse andere problemen die we hebben met Internet verkeer.

[plizz]

Je kunt de NAT rule volgorde aanpassen. Dat zal ook helpen.

[Rolfie]

plizz schreef op dinsdag 6 augustus 2019 @ 14:59:
Je kunt de NAT rule volgorde aanpassen. Dat zal ook helpen.

De NAT rule wordt op de ISP op hun firewalls uitgevoerd. Ik heb daar dus geen toegang toe.

[Yariva]

Dan is het alsnog erg vreemd... Hoe kan je een tunnel opbrengen achter een NAT constructie? Die zouden elkaar dan (zonder port forwarding) helemaal niet moeten kunnen bereiken. Weet je zeker dat het niet ergens anders aan ligt?

[DiedX]

Kunnen de gateways in de tunnel elkaar wel pingen? Routering?

[johnkeates]

Werkt het als je bijv. een test tunnel met OpenVPN opzet wel? Dan weet je in elk geval of het *kan* werken.

[ Voor 27% gewijzigd door johnkeates op 06-08-2019 16:34 ]

[Rolfie]

DiedX schreef op dinsdag 6 augustus 2019 @ 16:32:
Kunnen de gateways in de tunnel elkaar wel pingen? Routering?

Routering werkte, via het Internet en ik zag ook mijn verkeer aankomen op de firewall. Maar het issue was uiteindelijk een NAT issue bij de ISP.

johnkeates schreef op dinsdag 6 augustus 2019 @ 16:34:
Werkt het als je bijv. een test tunnel met OpenVPN opzet wel? Dan weet je in elk geval of het *kan* werken.

OpenVPN had ook vage issue. Zeker in het verleden. Ik heb een vermoeden dat dit wel eens de oorzaak kon zijn toen. Alleen nooit zo geconstateerd. Maar OpenVPN deed het wel, we gebruiken dit ook als VPN toegang. Maar heeft ook af en toe wat vage issues. Eens kijken of dat nu ook opgelost is.

Yariva schreef op dinsdag 6 augustus 2019 @ 16:05:
Dan is het alsnog erg vreemd... Hoe kan je een tunnel opbrengen achter een NAT constructie? Die zouden elkaar dan (zonder port forwarding) helemaal niet moeten kunnen bereiken. Weet je zeker dat het niet ergens anders aan ligt?

Het werkelijke probleem was dat de Internet provider in dit gebouw NAT had toegepast op onze IP's

code:

[2.4.4-RELEASE][[e-mail]]/root: tcpdump -i vmx0 port 22 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmx0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:23:30.332773 IP X.Y.Z.178.55792 > X.Y.Z.179.22: Flags [S], seq 1731898638, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
16:23:31.333139 IP X.Y.Z.178.55792 > X.Y.Z.179.22: Flags [S], seq 1731898638, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
16:23:33.333326 IP X.Y.Z.178.55792 > X.Y.Z.179.22: Flags [S], seq 1731898638, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
16:23:37.333907 IP X.Y.Z.178.55792 > X.Y.Z.179.22: Flags [S], seq 1731898638, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0

Dit was een tcpdump op de firewall. Ik deed op dit moment een SSH connect vanuit mijn A.B.C.155 IP adressen. Maar zoals je kunt zien kwam het verkeer op de firewall vanaf X.Y.Z.178.

De ISP heeft nu aanpassingen doorgevoerd en nu is de NAT er uit en werkt de IPSEC tunnel zonder enige problemen.
Het probleem is dus gelukkig opgelost .