10.08.2014, aktualisiert um 14:05:12 Uhr

18352

IPSec Site To Site mit pfSense hinter einer Fritzbox

Hallo,

ich komme hier nicht weiter und hoffe auf Unterstützung.
Ich habe einen IPSec Tunnel aufgebaut von meiner pfSense zu meiner Firma. Meine pfSense ist an eine Fritzbox angeschlossen.
Laut pfSense steht der Tunnel.
Ich kann nur leider kein Gerät auf der Gegenseite erreichen (ping oder anderes).

Aktuelle Konfiguration:
FritzBox LAN: 192.168.178.0/24
pfSense WAN-IP: 192.168.178.250
pfSense LAN: 192.168.100.0/24
Remote LAN: 10.0.0.0/8

Das habe ich bisher eingestellt auf der pfSense:
Firewall Rule (Für Testzwecke):
Floating any to any über alle Ports und Protokolle für IPv4
NAT Outbound:
Interface: IPSec/Source:any/Sorce port:*/Destination: 10.0.0.0/8/Destination Port:*/NAT Address:IPSec Address/NAT Port:*

Einstellung auf der fritzbox:
IPv4 Route: 10.0.0.0/8 an 192.168.178.250

Ich mache hier sicherlich einen großen Fehler, aber ich sehe den Wald vor lauter Bäumen nicht.

dasgunn

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 246103

Url: https://administrator.de/contentid/246103

Ausgedruckt am: 24.11.2024 um 02:11 Uhr

31 Kommentare

Neuester Kommentar

Hi,

zu meiner Firma.

..und was ist dort für die Sicherheit zuständig ?
- welche Hardware ?
- blockt eine FW ?
- Regeln erstellt ?
Gruß orcape

Auf der Gegenseite (auf der Seite meiner Firma) weiß ich nicht genau was da läuft. Da ich aber nicht der einzige bin der eine Site to Site Verbindung aufgebaut hat gehe ich davon aus, dass das Problem nicht dort liegt.
Ich glaube die Pakete gehen gar nicht erst in Richtung Tunnel.

Hallo,

Zitat von @dasgunn:
Auf der Gegenseite (auf der Seite meiner Firma) weiß ich nicht genau was da läuft.

Du weist NICHt was dort läuft aber versuchst ein Standort - Standort Netz dorthin aufzubauen?

Da ich aber nicht der einzige bin der eine Site to Site Verbindung aufgebaut hat

Kann da einfach jeder hingehen und sich dort ein Standort hin aufbauen(und das funktioniert)?

gehe ich davon aus, dass das Problem nicht dort liegt.

Sicher? Dir ist schon bekannt das ein Standort - Standort VPN an BEIDEN Seiten korrekt sein muss.

Ich glaube die Pakete gehen gar nicht erst in Richtung Tunnel.

Was ist das Routing? Was sagt ein Kabelhai? Wer hat noch dein 10.0.0.0/8 Netz? Wer hat an deiner Seite welche IP und von wo aus versuchst du es nach wohin?

Sicher das du von eine VPN Standort - Standort redest und nicht ein VPN Client zu Standort meinst oder brauchst? Was sagt der VPN Admin am Firmenstandort was du benötigst? Zertifikate? Schlüssel? Passwörter? IPs? Benutzer?

Gruß,
Peter

Hallo,

das kann man auf verschiedene und unterschiedliche Art und Weise lösen.

1 AVM FB als Router

Man nutzt die AVM FB als Router und öffnet dort mehrere Ports (Port Forwarding)
so das der VPN Dienst auf die pfSense weitergeleitet werden kann und dann dort das
VPN terminiert wird.

2 AVM FB als Modem

Man nutzt das nur das Modem der AVM Fritz!Box und deaktiviert dann eben
die VPN Benutzung und schließt die pfSense an LAN Port 1 der FB an, Ports
müssen dann keine mehr weitergeleitet werden (Port Forwarding)

3 Alternative

Man aktiviert am LAN Port 4 der AVM FB die DMZ Funktion und leitet die
Ports und Dienste (Port Forwarding) dann durch und hat den restlichen Router
dann für ein separates Netzwerk frei und beide Netze können dann in das Internet.

4 Alternative 2

Man kann wie in Alternative 1 beschrieben die DMZ Funktion an LAN Port 4
der AVM FB aktivieren und dann die Funktion des "Exposed Hosts" nutzen,
allerdings nur und ausschließlich für den LAN Port 4 der AVM FB und nicht
für alle Ports oder andere Ports an der AVM FB, sondern nur für den LAN Port 4
mit der aktivierten DMZ Funktion!!!

Gruß
Dobby

(auf der Seite meiner Firma) weiß ich nicht genau was da läuft.

..so in etwa hatte ich mir das schon gedacht.

Das ist schon sehr bedenklich für die Sicherheit eines Firmennetzwerkes, wenn da jeder so seinen eigenen Tunnel integrieren kann..

Ich glaube für den Rest ist wohl @Pjordorf's Ausführungen wenig hinzuzufügen.
Gruß orcape

Auf der Gegenseite (auf der Seite meiner Firma) weiß ich nicht genau was da läuft.

Na dann, und woher sollen wir das wissen bzw. wie sollen wir Dir eine Ziel gerichtete
Hilfe bei dem Fall leisten? Was sagt denn der Admin Eurer Firma dazu?

Da ich aber nicht der einzige bin der eine Site to Site Verbindung aufgebaut hat gehe

Davon aus gehen, glauben, meinen und all solche Sachen sind in der EDV wenig Ziel führend
denn hier sollte man schon wissen was auf der anderen Seite alles vorhanden ist und was, wie
eingestellt werden muss.

ich davon aus, dass das Problem nicht dort liegt.

Ich langsam auch denn Du solltest wirklich dringend mit Eurem Admin
reden und dann wird er Dir sicherlich Hilfestellung dazu geben.
Denn was auf beiden Seiten vorhanden ist sollte schon bekannt sein.

Mal was ganz anderes, warum terminierst Du denn das VPN nicht an der Fritz!Box?
Die kann IPSec und ist auch für solche Sachen nicht schlecht wenn es sich nur um
eine VPN Verbindung handelt.

Firewall Rule (Für Testzwecke):
Floating any to any über alle Ports und Protokolle für IPv4
NAT Outbound:
Interface: IPSec/Source:any/Sorce port:*/Destination: 10.0.0.0/8/Destination Port:*/NAT
Address:IPSec Address/NAT Port:*

Das ist alles sekundär es wäre erst einmal hilfreich was Du für ein "Port Forwarding"
an der AVM FB gemacht hast und welche weiteren Protokolle Du weitergeleitet hast!!!

Gruß
Dobby

Ein Blick ins Forumstutorial erklärt schon was mögliche Ursachen sein können:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Die häufigsten Fehler:

Port Forwarding vergessen einzustellen am vor der pfSense liegenden Router. Bei IPsec ist das UDP 500, UDP 4500, ESP Protokoll. Kann es aber bei dir vermutlich NICHT sein, denn würde das fehlen kann der VPN Tunnel schon gar nicht aufgebaut werden !!
In der pfSense am WAN Port den Haken entfernen das per Default generell RFC 1918 IP Netze (Private IPs) geblockt sind ! Das muss entfernt werden denn das lokale FB LAN dovor ist ja immer ein privates IP Netz !
Du kommst mit einem neuen privaten Absender IP Netz an den Endgeräten am anderen Ende des VPNs an. Normalerweise blocken die lokalen Firewall alle Zugriffen an fremden Absender IPs ! Hier musst du ggf. die lokale Firewall anpassen !
Wenn in dem remoten Netzwerk auch noch ein Router ist zusätzlich zur Firewall ist oft der Router als Default Gateway eingestellt und Antwort Pakete gehen so ins Nirwana ! Hier muss dann zusätzlich ein statische Route eingetragen werden ! Traceroute und Pathping sind dann immer deine Freunde !

Hi,
vielen Dank für Antworten. Hier mein Statement:
@aqui

Port Forwarding vergessen einzustellen...

Das ist an. Wie du richtig bemerkt hast, würde sich sonst der Tunnel nicht aufbauen.

In der pfSense am WAN Port den Haken entfernen das per Default generell RFC 1918...

Der Haken wurde bei allen Interfaces entfernt.

Du kommst mit einem neuen privaten Absender IP.....

Wenn ich die Firewall Regeln raus nehme müsste ich den Traffic sehen wie er geblockt wird, das passiert leider nicht. Ich gehe davon aus, dass er erst gar nicht den Weg in den Tunnel findet.

Wenn in dem remoten Netzwerk auch noch ein Router...

Siehe vorher. Ich gehe nicht davon aus, dass der Traffic überhaupt zum tunnel kommt.

@Pjordorf

Du weist NICHt was dort läuft aber versuchst ein Standort....

Das muss ich auch nicht wissen. Ich habe alle notwendigen Daten von meiner Firma bekommen. Außerdem wird der Tunnel aufgebaut, laut Log.

Was ist das Routing? Was sagt ein Kabelhai? Wer hat noch dein 10.0.0.0/8 Netz?

Das Routing und NAT ist bestimmt die Schwachstelle. In keinem von mir erreichbaren Bereich gibt es sonst noch ein 10.0.0.0/8 Netz. Ein Dopplung ist also ausgeschlossen.

@orcape
Wozu muss ich wissen welche Hardware in meiner Firma läuft?
Feststeht, dass der Tunnel steht und ich alle notwendigen Informationen von meiner Firma für diesen Tunnel erhalten habe. Ich glaube sogar dass es bedenklich wäre, wenn ich wüsste was da steht. Un da kann nicht jeder kommen und einen Tunnel auf machen. Der muss beantragt und freigegeben werden.

@108012
Ich nutze Möglichkeit 1. Die Ports sind offen und der Tunnel steht.

Hallo,

Zitat von @dasgunn:
>>Du weist NICHt was dort läuft aber versuchst ein Standort....
Das muss ich auch nicht wissen. Ich habe alle notwendigen Daten von meiner Firma bekommen

Vielleicht hat man dir aus Versehen falsche Daten gegeben....

Außerdem wird der Tunnel aufgebaut, laut Log.

Und dein Tunnel tut es aber NICHT. Das steht nicht im LOG. Er tut es nicht. Du hast also keinen Tunnel gebaut sondern ein Schwarzes Loch. Alles geht rein aber nichts kommt raus. Dir ist schon bekannt das ein Netzwerk nur dann funktionieren kann, wenn ein Kommunikation zwischen 2 Geräte / Software möglich ist. Einseitig zu reden erzeugt nur Datenmüll und blockierte Leitungen. Daher noch einmal, nimm den Kabelhai und schaue ob überhaupt etwas in dein Tunnel rein WILL. dann sehen wir weiter. Und ohne das du endlich sagst wer was und wo welche IP und Maske Gateway usw. hat kann dir hier keiner gezielt helfen außer dir das allgemeine nochmals runter zu beten.

Wozu muss ich wissen welche Hardware in meiner Firma läuft?

Nicht zwingend. Nur wenn es das nicht tut was du willst und du anfängst Fehler zu suchen......

Gruß,
Peter

Ich gehe nicht davon aus, dass der Traffic überhaupt zum tunnel kommt.

...dann wäre erst mal der Blick auf die Routingtabelle sinnvoll.
Tracert, Ping zum Tunnel etc.
Gruß orcape

Um etwas mehr Licht ins Dunkel zu bringen habe ich Screenshot erstellt und lade sie euch hoch.
Dabei sind:
- NAT Outbound
- traceroute Mitschnitt einer 10er IP auf Seite meines Arbeitgebers
- IPSec Log
- IPSec SAD
- IPSec SPD
- statische Routen FritzBox

Zitat von @dasgunn:
Firewall Rule (Für Testzwecke):
Floating any to any über alle Ports und Protokolle für IPv4

Hi,

bist Du sicher, dass Floating Rules standardmäßig auf (IPsec-)VPN angewandt werden? Dafür könnte das optionale Interface-Assignment des VPN Voraussetzung sein, und davon schreibst Du nichts; oder eben die Regeln individuell für das VPN einrichten.

Grüße
Richard

Hallo Richard,

das Floating kann man einstellen über welche Interfaces das laufen soll.
IPSec kann man nicht als dediziertes Interfaces anlegen. Das funktioniert meines Wissens nach nur mit OpenVPN. Da habe ich es zumindest schon gesehen.#

dasgunn

NAT Outbound ist auch völliger Blödsinn, denn das gilt ausschließlich nur wenn man IPsec durchleiten muss auf einen IPsec Host HINTER der pfSense im lokalen LAN.
Das ist ja hier nicht der Fall, da die pfSense ja SELBER als VPN Gateway der IPsec Host ist.
Schlimmer noch: Das NAT Outbound ist kontraproduktiv, denn es leidet die IPsec Frames weg von der pfSense salopp gesagt.
Diese Rule ist in dem Umfeld Unsinn und gehört entfernt.

Ok. Welche Regel muss ich entfernen?
Die des Interfaces IPsec?

IPsec Outbound-NAT ist raus. Hat aber am Verhalten nichts geändert.

OK, dein Design war eine Router Kaskade, richtig ??
Also
(Internet)====(FritzBox)----lokalesKoppel-LAN----(WANPort=pfSense=LANPort)----lokalesLAN----(PC)
Hier nochmal die ToDos dafür:

am WAN Port der pfSense statische IP einrichten die außerhalb des DHCP Pools der FB liegt, Gateway und DNS an der pfSense auf die FB IP einstellen.
Check an der pfSense unter Diagnostics mit Ping 8.8.8.8 das Internet Connectivity besteht
Port Forwarding an der FB vor der pfSense auf die WAN IP Adresse der pfSense einstellen: UDP 500, UDP 4500, ESP Protokoll (IP Protokoll Nr. 50 Achtung: KEIN TCP oder UDP 50 !!)
Default Firewall Blocker von RFC 1918 IP Netzen am WAN Port der pfSense entfernen !
pfSense Firewall Rule am WAN Port von Eingehend Source ANY auf die Destination WAN IP der pfSense für die o.a. 3 IPsec Ports bzw. Protokolle erlauben !
IPsec Verbindung aufbauen, diese sollte dann aktiv sein
Entsprechende lokale Interfaces an der remoten pfSense müssen pingbar sein. Voraussetzung ist das auf der anderen Seite genau die o.a. Schritte ebenfalls ausgeführt werden sollte sich die pfSense dort auch HINTER einem NAT Router befinden !
Firewall Rules auf dem Tunnel Interface entsprechen anpassen (PASS) das die Pakete der beiden lokalen LANs dort entsprechend im Tunnel passieren können. Oder testweise temporär eine "Schrottschussregel" any any auf diesen Tunnelinterfaces einrichten.

Das sind die minimalen ToDos damit es zum Laufen kommt ! Bitte auch das IPsec Tutorial:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
immer zu Rate ziehen !

Hallo aqui,

danke für deinen Beitrag. Richtig, es ist eine Kaskade.
Nun zu deinen Punkten:

am WAN Port der pfSense statische IP einrichten die außerhalb des DHCP Pools der FB liegt, Gateway und DNS an der pfSense auf die FB IP einstellen.

Der DHCP-Bereich der FB ist der folgende: 192.168.178.20 - 192.168.178.200. Die IP der pfSense auf WAN-Seite ist 192.168.178.250.
Gateway und DNS der pfSense sind 192.168.178.1 (IP-Adresse der FB).

Check an der pfSense unter Diagnostics mit Ping 8.8.8.8 das Internet Connectivity besteht.

Check! Der Ping geht läuft.

Port Forwarding an der FB vor der pfSense auf die WAN IP Adresse der pfSense einstellen: UDP 500, UDP 4500, ESP...

Es sind alle drei freigegeben an die 192.168.178.250.

Default Firewall Blocker von RFC 1918 IP Netzen..

Ist für jede Netzwerkschnittstelle deaktiviert.

pfSense Firewall Rule am WAN Port von Eingehend Source ANY

Ich habe die Firewall erstmal "auf Durchzug" gestellt. Es wird nicht geblockt egal in welcher Richtung kommend und gehend.
Dementsprechend ist das Log leer.

IPsec Verbindung aufbauen,

Die Verbindung steht.
Auszug aus dem IPSec-Log:
Aug 11 13:38:56 racoon: [XX]: INFO: IPsec-SA established: ESP 192.168.178.250[500]->80.XXX.XXX.XXX[500] spi=1255241981(0x4ad178fd)
Aug 11 13:38:56 racoon: [XX]: INFO: IPsec-SA established: ESP 192.168.178.250[500]->80.XXX.XXX.XXX[500] spi=250808577(0xef30901)
Aug 11 13:38:56 racoon: [XX]: INFO: respond new phase 2 negotiation: 192.168.178.250[500]<=>80.XXX.XXX.XXX[500]

Entsprechende lokale Interfaces an der remoten pfSense müssen pingbar sein.

Das sind sie leider nicht.

Was ich merkwürdig finde ist der Output des Traceroute:
Host: 10er IP die in den Tunnel gehen müsste
Protocol: IPv4
Source Address: LAN

Traceroute output:
1 192.168.178.1 (192.168.178.1) 0.713 ms 0.522 ms 0.765 ms
2 * * *
3 192.168.178.1 (192.168.178.1) 2.373 ms 1.511 ms 1.934 ms
4 * * *
Meine Interpretation ist, dass das Paket gar nicht zum Tunnel geht sondern an die FB gesendet wird.

Die zweite Merkwürdigkeit ist, wenn ich die Firewall zu mache für IPsec und nichts durch lasse, dann erscheint kein Eintrag mit einer 10er IP.
Das stützt meine erste Interpretation, das kein Paket zum Tunnel kommt.
Fehlt irgendeine Routing Einstellung?

Das Tutorial schaue ich mir jetzt an.

dasgunn

Aug 11 13:38:56 racoon: [XX]: INFO: IPsec-SA established: ESP 192.168.178.250[500]->80.XXX.XXX.XXX[500]

OK, das sieht gut aus ! Damit steht der IPsec VPN Tunnel und die PFW Settings sind OK !

>>Entsprechende lokale Interfaces an der remoten pfSense müssen pingbar sein.
Das sind sie leider nicht.

Das zeigt dann das die Firewall Regeln auf den VPN Tunnel Interfaces nicht oder falsch definiert sind ? Oder hast du dort auch "PASS any zu any" eingestellt ?
Ist remote auch eine solche Router Kaskade implementiert ??

Was ich merkwürdig finde ist der Output des Traceroute: Host: 10er IP die in den Tunnel gehen müsste

Ja, das muss in jedem Falle so sein !!
Sih dir dazu bei aufgebautem VPN Tunnel unter Diagnostics -> Route immer die Routing Tabelle an !!
Die muss auf ein Tunnel Interface zeigen !

Meine Interpretation ist, dass das Paket gar nicht zum Tunnel geht sondern an die FB gesendet wird.

Sieht nach dem Traceroute auch erstmal so aus ?? Ist die IPsec Konfig richtig, das dieses Netz als remote Net definiert ist ??

Die zweite Merkwürdigkeit ist, wenn ich die Firewall zu mache für IPsec und nichts durch lasse, dann erscheint kein Eintrag mit einer 10er IP.

Das ist ja normal, denn wenn der Tunnel nicht aufgebaut wird steht auch kein 10er Netz in der Routing Tabelle.
Nur mal dumm nachgefragt: Einen Subnetz Mismatch mit der 10er IP hast du nicht zufällig ?

Hier die Konfiguration von IPsec:

Das sollte passen.
Ein weiteres 10er Netz ist bei mir nicht vorhanden.

Hallo dasgunn!

Phase 2: Was ist denn 10.107.54.3 für eine lokale Adresse? Standardmässig gehört bei einem Site-To-Site Vpn hier das lokale LAN Subnet rein. Abweichende lokale IP's kenne ich nur von Clientverbindungen. Teste das mal.

Hast du eine Rule auf deinem IPSec Interface, die allen Traffic erlaubt?

Gruß
Buc

Hi!
Die 10.107.54.3 ist die IP des Tunnels. Wenn ich hier etwas anderes eintrage, dann wird der Tunnel nicht aufgebaut.

dasgunn

Setz doch bitte mal die IPSec-interface Firewall Rule auf Source: any, Destination any.

Wie man mit einer festen zugewiesenen IP aus dem Remotenetz z.B. mit dem Shrew Client eine Verbindung aufbaut, könnte ich dir sagen. Site-to-Site verbindet halt nunmal Netzwerke. Wie das mit einer IP geht? ... Routen?

Bist Du dir sicher, dass dein Admin nicht nur einen Client-Zugang möchte?

Aus der PfSense Dokumentation zum Thema:

"Local subnet: This defines which subnet or host can be accessed from the other side of the VPN tunnel. The easiest thing to do is to set this to "LAN subnet". This means the entire LAN will be accessible from the remote network. IMPORTANT: The other end of the tunnel has this same field, except on the far side it is "Remote Subnet". Ensure that the other end is set exactly the same. For example, if "Single host" is chosen in this section and the IP address of a host was entered, the other side would need to set that host in the "Remote Subnet" field."

Remote Subnet: This defines which subnet or host to be accessed on the other end of the tunnel. As mentioned in the previous item, it is paramount that this is set this exactly like the other end's "local subnet" section. If not, phase 2 of the VPN connection will fail and traffic will not pass from one VPN segment to the other. "

Nichts in deinem Netzwerk hat deine in Phase 2 angegebene IP. Somit ist auch nichts erreichbar. Ein Client wie Shrewsoft routet das dann automatisch, wie das mit der pfSense gehen soll, weiss ich denn leider auch nicht. Du müsstest der Pf halt irgendwie ein Interface mit dieser IP verpassen und das dann bridgen...

Da ich das aber von vorneherein anders konzipiert hätte, bin ich für die Details da raus.

Evtl. guckt ja @aqui nochmal, oder einer von den vielen anderen, die das auch hintergründiger verstehen, weil sie sich auf der Uni damit abgequält haben.

Gruss vom Buc

Ich tippe auch auf Routing. Weiß es aber nicht genau. Meine Idee ist gewesen ein Gateway einzurichten auf die IP des Tunnels und dann alle Anfragen dahin zu leiten. Das funktioniert nur leider nicht, da ich nur Gateways erstellen kann mit einer IP aus einem Netz welches die pfSense kennt,

Es ist definitiv kein Client Zugang, da unsere Firma das mit OpenVPN löst.
Mittlerweile schließe ich eine Fehlkonfiguration auf der Seite meines Arbeitgebers nicht aus. Nur müsste ich mit handfesteren Argumenten kommen und nicht mit Vermutungen.
@the-buccaneer
Danke dir für deine Hilfe!

dasgunn

Nur müsste ich mit handfesteren Argumenten kommen und nicht mit Vermutungen.

Da der VPN Tunnel ja fehlerfrei rennt kann es eigentlich nur die Firewall Konfig der anderen Seite sein. Hier musst du dir einen Konfig Snapshot schicken lassen ggf. auch anonymisiert um das checken zu können.
Wie immer hat man dort vermutlich vergessen mit einer zusätzlichen regel dein lokales LAN freizugeben !
So eine Firewall Konfig ist immer einen enge Abstimmen BEIDER Seiten !
Wenn die andere Seite nicht kooperiert scheitert sowas in der Regel. Das sagt einem aber auch schon der gesunde IT Menschenverstand ?!

Da hat du Recht.
Ich stelle eine Anfrage.

dasgunn

Zitat von @dasgunn:

Da hat du Recht.
Ich stelle eine Anfrage.

dasgunn

Hallo nochmal,

was für ein Internetanbieter (ISP) ist denn auf beiden Seiten des Tunnels vorhanden.

Gruß
Dobby

Hallo,

auf meiner Seite ist Kabeldeutschland. Auf der anderen Seite ist Telekom.
dasgunn

Das sollte eigentlich kein Problem sein es sei denn Kabeldeutschland filtert IPsec bei Consumer Anschlüssen.
Die Telekom (T-Com) lässt das durch sowohl auf Business als auch auch Consumer DSL Anschlüssen.
Filtern entfällt aber als Problem, denn wäre dem so würde niemals ein IPsec VPN Tunnel zustande kommen, was er hier aber problemlos tut !!
Das Problem ist zu 98% eine falsche oder fehlende Firewall Einstellung auf der anderen Seite !

Problem gelöst!
Es war eine Fehlkonfiguration der Phase 2.
Als Local Network muss natürlich mein LAN Netzwerk eingetragen werde und beim Local Network NAT muss die 10er IP des Tunnels eingetragen werden.
Jetzt läuft es.

Ein großes Danke an alle.

dasgunn