[Cisco] ASA5510 route naar extern adres eigen netwerk

[Snors]

Allen,

Ik ben het spoor bijster met het volgende:
Ik heb een server die zowel intern als extern benadert wordt. Voor het externe gedeelte hebben we een NAT rule aangemaakt namelijk:

37.74.xx.xxx(EXTERN IP):443 -> 10.xx.xx.xx(INTERN IP):4443

Oftwel Poort 443 extern wordt getranslate naar poort 4443 intern. Dit werk prima als je bijvoorbeeld een telnet verbinding opzet vanaf een computer buiten ons netwerk:

telnet 37.74.xx.xxx(EXTERN IP) 443

Echter loop ik nu tegen het volgende probleem aan namelijk dat ik vanaf binnen ons netwerk ook dit EXTERNE adres moet benaderen op poort 443 i.p.v. via het interne adres. Dit i.v.m. certificaten namelijk dat hij de connectie met ons externe godaddy certificaat valideert i.p.v. ons eigen gegenereerde CA Root certificate. Beide certificaten zijn valide echter heb ik geen zin om dit certificaat op alle Android / Iphone toestellen te installeren aangezien het externe IP door mobile devices benadert wordt. Op dit moment krijg ik geen verbinding als ik
telnet 37.74.xx.xxx(EXTERN IP) 443 uitvoer.

Echter als ik Packet Tracer gebruik in de ASA5510 en mijn workstation IP als Source IP opgeef en het EXTERN IP als destination en TCP poort 443 gebruik hij wel gewoon aangeeft dat iig de firewall het verkeer doorlaat.

Lang verhaal maar ik hoop een beetje in de juiste richting geduwt te kunnen worden.. Thanks alvast

[Kompaan]

je hebt NAT Reflection/Loopback nodig, i.e. de translation werkt van buiten naar binnen, maar net van binnen naar binnen, geen idee of dat kan.

Gaat dit niet goed als je vanaf intern https://<extern_ip>:4443 doet?

[Snors]

Het gaat om de Mobile client van Microsofy Lync. Aangezien ze aanbevelen om het "Reverse Proxy Extern IP" te gebruiken voor zowel intern als extern, dit omdat je niet op elk Iphone/Android toestel die Inter ngebruikt wordt het CA certificate van je eigen CA server handmatig wilt installeren. Vandaar dat ik dus op onze interne DNS server een "Lyncdiscover" A record aanmaakt die naar ons externe IP adres verwijst aangezien de mobile client dit dan toepast. Ik check altijd of een poort open staat en te benadere is d.m.v. Telnet. Als ik op een PC buiten ons netwerk(bijv. mijn thuis PC) een telnet sessie open op het Externe IP dan werkt dit:

telnet 37.74.xx.xxx(EXTERN IP) 443

Als ik dit intern probeer dan gaat het idd dus fout omdat je van binnen -> buiten wilt gaan en weer terug(geen idee of dit logisch is) omdat er geen webserver achter poort 443 draait maar een Lync service is de enige manier om het of elke keer met de Lync mobile client proberen te connect of het bovenstaande Telnet commando. Ik ben er namelijk van overtuigd dat als je kan telnetten het werkt. Het is 100% een firewall issue omdat het allemaal buiten ons netwerk wel werkt.

Om je laatste vraag te beantwoorden als ik:

telnet 10.xx.xx.xx(INTERN IP) 4443 doe dan werkt het gewoon op het interne netwerk maar de mobile client werkt niet op dit adres omdat hij dan het certificaat niet kan valideren..

[ Voor 9% gewijzigd door Snors op 04-04-2013 17:10 ]

[Paul]

Het is een beetje jammer dat je op 10.xx.xx.xx(INTERN IP) een afwijkende poort gebruikt, anders kon je split DNS gebruiken. Heb je de mogelijkheid een extra ip aan de webserver te knopen en de bindings van de site aan te passen? Dan hoeft je verkeer helemaal niet meer via de ASA...

[Linke Loe]

Ik begrijp uit jouw verhaal dat het IP-adres wat jullie gebruiken voor outbound verkeer (dus wat je te zien krijgt bij www.watismijnip.nl) en het IP-adres waar je je Lync front-end server op publiceert hetzelfde is? Dan sta je inderdaad voor een uitdaging. Heb je niet de mogelijkheid om een ander IP-adres te gebruiken om de web-services te publiceren?

Het is dan ook niet voor niets best practice om 4 externe IP-adressen te reserveren voor externe Lync toegang: een IP-adres voor de reverse proxy, die de web services publiceert, een IP-adres voor de SIP access edge, een voor de webconferencing edge en een voor de A/V authentication service. Deze laatste drie kunnen eventueel wel gecombineerd worden door NAT toe te passen, of deze services op andere poorten te laten draaien. Ik neem ook aan dat je dit gelezen hebt in de Technet documentatie over Lync, voordat je begon aan de inrichting?

Overigens zou ik persoonlijk zo veel mogelijk gebruik maken van CNAME records in plaats van A records. Ik heb op onze interne DNS server dan ook een CNAME voor lyncdiscoverinternal.sipdomein.nl aangemaakt, die verwijst naar de externe FQDN, die gepubliceerd wordt door onze TMG proxy.

[ Voor 13% gewijzigd door Linke Loe op 04-04-2013 22:22 ]

[Snors]

Linke Loe schreef op donderdag 04 april 2013 @ 22:18:
Ik begrijp uit jouw verhaal dat het IP-adres wat jullie gebruiken voor outbound verkeer (dus wat je te zien krijgt bij www.watismijnip.nl) en het IP-adres waar je je Lync front-end server op publiceert hetzelfde is? Dan sta je inderdaad voor een uitdaging. Heb je niet de mogelijkheid om een ander IP-adres te gebruiken om de web-services te publiceren?

Het is dan ook niet voor niets best practice om 4 externe IP-adressen te reserveren voor externe Lync toegang: een IP-adres voor de reverse proxy, die de web services publiceert, een IP-adres voor de SIP access edge, een voor de webconferencing edge en een voor de A/V authentication service. Deze laatste drie kunnen eventueel wel gecombineerd worden door NAT toe te passen, of deze services op andere poorten te laten draaien. Ik neem ook aan dat je dit gelezen hebt in de Technet documentatie over Lync, voordat je begon aan de inrichting?

Overigens zou ik persoonlijk zo veel mogelijk gebruik maken van CNAME records in plaats van A records. Ik heb op onze interne DNS server dan ook een CNAME voor lyncdiscoverinternal.sipdomein.nl aangemaakt, die verwijst naar de externe FQDN, die gepubliceerd wordt door onze TMG proxy.

Hmm, sounds interesting, we gebruiken overigens niet ons outbound IP maar we hebben een dedicated extern IP blok waarvan we verschillende IP adressen gebruiken voor onze Lync appliance maar ook bijv. Exchange etc. Anyway, wij hebben dus een eigen interne en externe DNS server het probleem is dat al onze interne PC's met onze interne DNS servers verbinding maken. Bijkoment probleem is dat ons domein / DNS voor zowel intern als extern dezelfde FQDN gebruikt dus: companyx.com

Een CNAME record voor lyncdiscoverinternal zou moeten helpen maar mijn main probleem is dus dat ik uberhaupt niet vanuit Intern met een van onze externe IP's een telnet sessie kan opzetten over poort 443. Een visio overzicht ter verduidelijking van mijn probleem:


Wat ik dus eigenlijk wil creeren is dat als iets uit onze externe IP reeks(37.74.25.xxx) wordt benadert vanuit ons interne netwerk onze ASA een "Loop" aanmaakt die het verkeer vanaf de Inside interface doorstuurt naar de Outside interface en het verkeer opnieuw binnen laten komen alsof het vanaf buitenaf komt... Op dit moment krijg ik totaal geen response als ik met onze Interne netwerk ben verbonden op 37.74.25.xxx terwijl dit vanaf extern wel mogelijk is.

[Paul]

Als het niet mogelijk is de default poort (al dan niet op een extra IP-adres) te gebruiken op de webserver (dat is, samen met split DNS, namelijk de schoonste oplossing) dan heb je hier mogelijk iets aan: http://ckdake.com/content...ing-with-a-cisco-asa.html

[Linke Loe]

Bij ons is dit geen enkel probleem. Ook wij hebben een ASA5510 in ons datacenter hangen en hebben daar 3 externe IP-subnets aan hangen. Op interface eth0 hebben we 80.x.x.106 en deze hangt direct aan het Internet. Op interface eth1 hebben we verschillende VLAN's waaronder twee publieke subnets: 80.x.x.136/29 en 80.x.x.160/27. In het eerste subnet hebben we .138 gereserveerd voor de web services en in het tweede subnet hebben we de .176, .177 en .178 gereserveerd voor de Lync edge server.

Vanaf ons interne netwerk kunnen wij moeiteloos al deze IP-adressen benaderen. Ook wij hebben 'domein.com' als Active Directory domeinnaam, maar onze SIP domeinen zijn land-gebonden, dus 'domein.nl', 'domein.be' etc, zodat iedereen zijn eigen e-mailadres kan gebruiken om in Lync in te loggen... Onze Lync web-services zijn op de TMG wel gepubliceerd onder 'domein.com'. Ik heb dus op onze interne DNS servers een zone aangemaakt voor ieder land. Hier heb ik de nodige SRV-records aangemaakt en het CNAME record 'lyncdiscoverinternal.domein.nl' die verwijst naar 'lync.domein.com'. Dit werkt feilloos...

Het enige verschil wat ik zo even zie, is dat jullie een appliance hebben. Ik heb geen idee hoe dat in elkaar steekt... Wij hebben namelijk drie VM's draaien: een Lync front end server, een Lync edge server en een TMG proxy server.

Wat zie je in de logging voorbij komen op de ASA, op het moment dat je verbinding wil maken met het externe IP-adres?

[Oid]

als ik het zo lees gebruikt TS geen TMG/Reverse proxy (anders dan NAT via de ASA). kijk hier eens bijv.
http://mytricks.in/2011/1...oft-lync-edge-server.html
http://www.shudnow.net/20...-corporate-wifi-networks/
http://ucken.blogspot.nl/...web-services-without.html

[Snors]

Oid schreef op vrijdag 05 april 2013 @ 20:48:
als ik het zo lees gebruikt TS geen TMG/Reverse proxy (anders dan NAT via de ASA). kijk hier eens bijv.
http://mytricks.in/2011/1...oft-lync-edge-server.html
http://www.shudnow.net/20...-corporate-wifi-networks/
http://ucken.blogspot.nl/...web-services-without.html

Ik heb net http://ucken.blogspot.nl/...web-services-without.html doorgelezen. Dat redirecten van de poorten ETC werkt dus wel gewoon OK. Ik snap waar jullie me heen willen sturen maar in princiepe werkt gewoon alles oke. Het enige probleem is dat ik geen zin heb om op iedereen die een mobiele telefoon hier heeft ons CA root certificate te installeren voor de interne certificaten. Ik wil dus alleen puur en alleen lyncdiscover / lyncdiscoverinternal doorverwijzen naar ons externe IP adres zodat hij dit certificaat gaat gebruiken. Echter gaat er dus iets mis op firewall niveau omdat hij mij niet vanaf ons intern netwerk onze externe adressen laat bereiken. Alsof die in een soort van loop terecht komt...

Ik ben zelf geen Lync Master en we hebben ook gewoon een implementatie partner, deze refereert alleen telkens dat het door onze firewall/DNS komt en het daar in opgelost moet worden.. Beetje hun woord tegen mijn woord zegmaar.

Thanks voor alle suggesties maar het zou mooi zijn als we dit op firewall niveau kunnen oplossen of dat ik in ieder geval gericht een tegen antwoord kan geven aan onze implementatie partner.

[Linke Loe]

Aan Lync ligt het niet, dus je hoeft inderdaad niet je Lync partner aan te spreken. Dit is inderdaad een firewall issue, vandaar dat ik in een eerdere post ook al vroeg wat je in de logging op je ASA voorbij ziet komen, op het moment dat je probeert verbinding te maken met het externe IP-adres. Wij hebben namelijk exact dezelfde setup die jij beschrijft en ik kan prima vanuit ons interne netwerk het externe IP-adres van onze TMG server bereiken. Dit externe IP-adres zit uiteraard wel in een ander VLAN als het externe IP-adres waaronder ons interne netwerk naar buiten gaat.

[Snors]

Linke Loe schreef op maandag 08 april 2013 @ 17:03:
Aan Lync ligt het niet, dus je hoeft inderdaad niet je Lync partner aan te spreken. Dit is inderdaad een firewall issue, vandaar dat ik in een eerdere post ook al vroeg wat je in de logging op je ASA voorbij ziet komen, op het moment dat je probeert verbinding te maken met het externe IP-adres. Wij hebben namelijk exact dezelfde setup die jij beschrijft en ik kan prima vanuit ons interne netwerk het externe IP-adres van onze TMG server bereiken. Dit externe IP-adres zit uiteraard wel in een ander VLAN als het externe IP-adres waaronder ons interne netwerk naar buiten gaat.

Ik zal dit doen en het resultaat hier even posten, als ik Packet Tracer gebruik krijgt deze wel gewoon een link bij ons is het wel zo geconfigureerd dat het externe IP adres niet op de interface staat geconfigureerd maar d.m.v. NAT deze wordt gerouted naar de interne servers(zoals aangegeven in de URL die hierboven gepost is). Ik zal de logs ff capturen vanaf het moment dat ik verbinding maak en even filteren op mijn IP adres dan weten we denk ik al meer inderdaad..

Thanks

EDIT: Wat ik dus zie is dat hij via onze Outside interface naar buiten gaat maar vervolgens vanaf daar zijn weg niet meer weet en de boel dus dropt. "Teardown dynamic TCP translation from inside: 10.24.xx.xx to outside: <Outside IP adres>

[ Voor 9% gewijzigd door Snors op 08-04-2013 17:33 ]

[Linke Loe]

Snors schreef op maandag 08 april 2013 @ 17:08:
[...]


bij ons is het wel zo geconfigureerd dat het externe IP adres niet op de interface staat geconfigureerd maar d.m.v. NAT deze wordt gerouted naar de interne servers(zoals aangegeven in de URL die hierboven gepost is).

Dan zit hier het verschil met onze setup. Wij hebben op eth0 van de ASA het externe IP-adres geconfigureerd waarmee het interne netwerk naar buiten toe ge-NAT wordt. Op eth1 van de ASA hebben we verschillende VLAN's, waaronder twee met een extern IP-subnet. In het ene VLAN zit onze TMG, in het andere VLAN zit de Lync edge server. Verkeer wordt gerouteerd tussen eth0 en deze twee VLAN's op eth1, dus er wordt hier bij ons geen NAT toegepast. Hebben jullie ook niet de mogelijkheid om het op deze manier in te richten?

[Snors]

Linke Loe schreef op maandag 08 april 2013 @ 19:25:
[...]

Dan zit hier het verschil met onze setup. Wij hebben op eth0 van de ASA het externe IP-adres geconfigureerd waarmee het interne netwerk naar buiten toe ge-NAT wordt. Op eth1 van de ASA hebben we verschillende VLAN's, waaronder twee met een extern IP-subnet. In het ene VLAN zit onze TMG, in het andere VLAN zit de Lync edge server. Verkeer wordt gerouteerd tussen eth0 en deze twee VLAN's op eth1, dus er wordt hier bij ons geen NAT toegepast. Hebben jullie ook niet de mogelijkheid om het op deze manier in te richten?

De mogelijkheid is er natuurlijk altijd.. maar een heel netwerk opnieuw inrichten voor alleen lyncdiscover ik kan gewoon niet begrijpen waarom dit zo'n probleem moet zijn. Externe certificaten aan de interne services koppelen is volgens mij ook niet "Best practise"...

[Paul]

Tja, als je het als interne service wilt benaderen en daar 'interne certificaten' (Die van je eigen root CA?) aan wilt hangen dan heeft dat inderdaad als consequentie dat je devices een certificate warning krijgen (of het root-CA moeten vertrouwen).

Wil je dat niet dan moet je intern ook een officieel certificate gebruiken. Maar dan zit je dus weer met het feit dat het bij jou op een niet-standaard poort draait?

Wat heb je nu al geprobeerd? Want ook na nogmaals lezen lijkt me die hairpin-link van mij nog steeds van toepassing: Je wilt weer naar binnen op de interface waarop je ook naar buiten ging

[Snors]

Paul schreef op maandag 08 april 2013 @ 22:00:
Tja, als je het als interne service wilt benaderen en daar 'interne certificaten' (Die van je eigen root CA?) aan wilt hangen dan heeft dat inderdaad als consequentie dat je devices een certificate warning krijgen (of het root-CA moeten vertrouwen).

Wil je dat niet dan moet je intern ook een officieel certificate gebruiken. Maar dan zit je dus weer met het feit dat het bij jou op een niet-standaard poort draait?

Wat heb je nu al geprobeerd? Want ook na nogmaals lezen lijkt me die hairpin-link van mij nog steeds van toepassing: Je wilt weer naar binnen op de interface waarop je ook naar buiten ging

We hebben een externe DNS server intern draaien(in onze DMZ) maar ook een in de cloud(buiten onze firewall dus) die repliceert met de externe DNS server die intern draait.

Volgens jou artikel zou dan:

code:

static (inside,outside) 192.168.0.193 172.16.0.10 netmask 255.255.255.255 dns

Moeten werken, nu vraag ik mij alleen af welke adressen ik waar moet invullen:
192.168.0.193 Moet dit ons interne IP zijn van lyncdiscover?
172.16.0.10 Moet dit ons Externe DNS IP zijn van de server?

Alvast bedankt!

[Paul]

Dat (DNSwerkt niet (dns) omdat je ook naar een andere poort translate / de website draait op een niet-standaard poort. Het gaat om de 'same interface'-regel (en de rest onder de solution).

Welk IP je waar in moet vullen kun je vinden bij 'The Setup'.

[Snors]

Paul schreef op dinsdag 09 april 2013 @ 12:32:
Dat (DNSwerkt niet (dns) omdat je ook naar een andere poort translate / de website draait op een niet-standaard poort. Het gaat om de 'same interface'-regel (en de rest onder de solution).

Welk IP je waar in moet vullen kun je vinden bij 'The Setup'.

We praten volgens mij een beetje langs elkaar heen de website EXTERN draait gewoon op poort 443(standaard poort) maar deze wordt getranslate naar INTERN poort 4443(niet standaard poort)...

Ik ga eens in de CLI kijken wat er al instaat en wat ik wellicht moet aanpassen om dit werken te krijgen. Ik zal deze post aanpassen.

[ Voor 11% gewijzigd door Snors op 09-04-2013 13:45 ]

[Paul]

Snors schreef op dinsdag 09 april 2013 @ 13:42:
We praten volgens mij een beetje langs elkaar heen

Nee hoor, dat had ik al lang door. Dat is dan ook precies de reden waarom je zo moet prutsen met hairpinning, loopback etc.

Had het ding intern netjes op de default poort gehangen dan had je namelijk gewoon tegen je interne DNS-server kunnen zeggen "autodiscover.bedrijf.com A 10.x.y.z" en dan was je klaar geweest.

Is het mogelijk een extra IP aan die webserver te hangen? Dan ben je er ook, want dan kun je op dat IP weer poort 443 gebruiken voor je SSL-site.

[Linke Loe]

Paul schreef op dinsdag 09 april 2013 @ 13:50:
[...]

Nee hoor, dat had ik al lang door. Dat is dan ook precies de reden waarom je zo moet prutsen met hairpinning, loopback etc.

Had het ding intern netjes op de default poort gehangen dan had je namelijk gewoon tegen je interne DNS-server kunnen zeggen "autodiscover.bedrijf.com A 10.x.y.z" en dan was je klaar geweest.

Is het mogelijk een extra IP aan die webserver te hangen? Dan ben je er ook, want dan kun je op dat IP weer poort 443 gebruiken voor je SSL-site.

We praten hier over Lync... Ik weet niet hoeveel ervaring je hiermee hebt, maar op een Lync front end server worden altijd twee websites aangemaakt: een internal site op poort 443 en een external site op poort 4443. Volgens de best-practice is het de bedoeling dat de externe site gepubliceerd wordt op poort 443 door een reverse proxy server. Het kan echter ook werken als je geen reverse proxy hebt, door je firewall poort 443 te laten bridgen naar 4443.

Wat ik van TS heb begrepen werkt dit ook gewoon, behalve als de client zicht op het interne netwerk bevindt. De ASA heeft dan blijkbaar moeite met het terug routeren van verkeer wat vanaf hetzelfde netwerk afkomstig is.

Hoe is de ASA ingericht met betrekking tot interfaces, IP-subnets en VLAN's? Welke NAT en access rules zijn er?

[Paul]

Linke Loe schreef op dinsdag 09 april 2013 @ 16:22:
We praten hier over Lync... Ik weet niet hoeveel ervaring je hiermee hebt,

Geen Ik zie een (niet-triviale of niet-'alleen voor management') website op een niet-standaard poort en denk WTF maar blijkbaar is dat by design...

[Snors]

We hebben 3 interfaces in gebruik:
Ethernet0/0 - DMZ
Ethernet0/1 - Inside
Ethernet0/2 - Outside

VLAN's staan op de switches geconfigureerd eigenlijk alleen een aparte VLAN voor de DMZ rest zit gewoon in de Default.

De security rules zijn er heel wat(voor Lync moeten nog al wat poorten open worden gezet) en geloof dus niet dat het met een van de poorten te maken heeft(443 en 4443 staan beide open). De NAT Rules daarintegen zijn het belangrijkste. Met name de NAT Rule die de port translation van 443 outside naar 4443 inside doet:


Deze nat rule werkt gewoon als ik bijvoorbeeld vanaf mijn thuis pc telnet 37.74.xx.xxx(EXTERN IP) 443 doe dan werkt dit gewoon. Echter wanneer ik dit vanuit mijn netwerk doe dan werkt dit niet.

[Linke Loe]

Ik neem aan dat het extern IP-adres van LYNCFRONTEU_Public een IP-adres in de DMZ is? Heb je in dat geval ook een NAT en access-rule van Inside naar DMZ?

[DukeBox]

^ Dat dus.. zie nu pas dat daar hetzelfde staat.

Snors schreef op donderdag 11 april 2013 @ 09:30:
Deze nat rule werkt gewoon als ik bijvoorbeeld vanaf mijn thuis pc telnet 37.74.xx.xxx(EXTERN IP) 443 doe dan werkt dit gewoon. Echter wanneer ik dit vanuit mijn netwerk doe dan werkt dit niet.

Op IP zal dat niet werken zonder hairpinning. Nadeel daarvan is dat het alleen werkt met static NAT's en niet met PAT's.. en dat heb jij nodig.

Het makkelijkste is om split dns te gebruiken (zoals je zelf al aangeeft) en een 2e PAT rule van 4443 -productie naar 443 - dmz.

[ Voor 4% gewijzigd door DukeBox op 11-04-2013 10:44 ]

[Snors]

Ok de PAT rule van 4443 productie naar 443 DMZ bestond al.. Dan is het alleen een kwestie van Split DNS te gebruiken zoals hierboven wordt aangegeven. Ik begrijp het concept maar nu de uitvoering nog...

code:

static (inside,outside) <DMZ IP FRONTEND SERVER HIER(INTERN DUS)> <IP EXTERNE DNS SERVER> netmask 255.255.255.255 dns

Klopt dit? Of begrijp ik nog steeds iets verkeerd

[Paul]

Je hebt al 2 verschillende DNS-servers (tenminste, je tekent er één maar noemt die wel 'internal'), dan zou ik in die internal DNS gewoon "lyncautodiscover CNAME LYNCFRONTEU_Public" (of het A-equivalent) invullen in de juiste zone (of een zone aanmaken die "lyncautodiscover.extern.com" heet aanmaken met daarin een A-record @, een beetje afhankelijk van je huidige opzet).

Je kunt ook tegen de ASA zeggen dat deze iets met DNS moet doen maar dan ga je dingen op verschillende plaatsen instellen; voor de overzichtelijkheid zou ik DNS bij de DNS-server houden en routering / translation / filtering op de ASA.

Split DNS is dus eigenlijk gewoon 2 DNS-servers hebben die beiden een ander IP-adres terug geven op dezelfde hostname. De DNS-server die 'de wereld' laat weten waar ze '(lyncautodiscover.)extern.com' kunnen vinden (mogelijk/meestal staat deze bij je hostingprovider) geeft je 37.74.25-adres terug, de DNS-server die clients op je interne netwerk bedient (die staat dus over het algemeen in je interne netwerk en kent ook je interne zones zoals bijvoorbeeld het AD) geeft op diezelfde naam je 10.24.0-adres.

[Snors]

Bedankt voor al jullie input maar het probleem word totaal verkeerd opgevat in mijn optiek. We hebben inderdaad een interne EN externe DNS server. Was het maar zo simpel om gewoon het A record van lyncdiscover / lyncdiscoverinternal naar LYNCFRONTEU_Public te verwijzen(of zoals je aangeeft het A-quivalent). Dat is JUIST het eerste wat ik heb geprobeerd omdat dit ook iets is wat ik wil bereiken.

Echter; Dit werkt dus niet vanaf het interne netwerk kan ik niet het A equivalent verwijzen van LYNCFRONTEU_Public(dus het 37.74.25.adres) Interne DNS geeft deze wel netjes terug maar verbinding maken HO maar....Split DNS heb ik dus al echter nu nog de Firewall. Kan ik dit bereiken door:

code:

static (inside,outside) <DMZ IP FRONTEND SERVER HIER(INTERN DUS)> <IP EXTERNE DNS SERVER> netmask 255.255.255.255 dns

Het zal ongetwijfeld aan mijn uitleg liggen maar het probleem is eigenlijk heel simpel. Vanuit het interne netwerk verbinding maken met Lync via het externe adres.

[_-= Erikje =-_]

Dat is toch juist niet split DNS? Split DNS geeft vanaf het interne netwerk een intern IP terug, vanaf het externe netwerk een extern ip

[DukeBox]

Volgens mij is nog het grootste probleem dat je server niet in DMZ hangt maar in INSIDE. Dan kan je dus niet 2x een PAT doen vanuit INSIDE en OUTSIDE naar je DMZ zoals geopperd wordt.

[Paul]

Mogelijk heb ik het verkeerde IP-adres maar je zegt zelf dat de PAT-rule van productie naar DMZ al bestaat...

Ik heb het even uitgetekend in de hoop de situatie wat duidelijker te krijgen:


Klopt dit plaatje? En wat zegt die PAT-rule?

code:

static (inside,outside) tcp (WLAN_GW of alias) https (Lync_DMZ_IP) 4443  netmask 255.255.255.255

Dat zou moeten werken mijns inziens... Dan moet je alleen tegen je wireless clients zeggen dat ze Lync (autodiscover) op (WLAN_GW of alias) kunnen vinden.

Je kunt kijken of je alles dat naar (LYNC_DMZ_IP):443 verzonden wordt kunt herschrijven naar (LYNC_DMZ_IP):4443 maar ik weet niet of je de site op de default poort nog nodig hebt, en misschien kun je ook een alias maken in DMZ (of mogelijk werkt een niet-bestaand IP ook, als de ASA toch herschrijft...) en alles wat daarheen gaat op 443 herschrijven naar (LYNC_DMZ_IP):4443

[pablo_p]

De oplossing is goed mogelijk, maar je wat je moet doen is direct je functionele wens te implementeren en niet denken aan de technische oplossing door de flow over je outside interface te halen.

Wat je wilt is in je inside netwerk een server a (met IP adres a.a.a.a) te benaderen op een ander IP adres A.A.A.A (wat toevallig je outside interface IP adres is, maar dta maakt niets uit).

Je hebt dus een NAT rule nodig van:

Real adres
- interface: DMZ
- IP address: a.a.a.a
- original port: 4443

Static translation
- interface: Inside
- IP address: A.A.A.A
- translated port: 443

Dit volstaat. Je hoeft niets te doen met het gegeven dat het IP adres al bekend is op je outside interface. Je hoeft verkeer daar niet (virtueel) overheen te halen.

Deze implementatie is gewoon rechttoe-rechtaan, je hebt geen extra trucs nodig.

P.S. Pas op, deze achtergrond informatie kan verwarrend zijn, maar is voor net iets andere wensen wel nodig. Als je NAT reflection wilt doen naar dezelfde interface, heb je een truc nodig. Dan krijg je een NAT van inside -> inside, met een PAT van de source IP adressen naar het inside interface IP adres van de firewall om het teruggaande verkeer door de firewall heen te trekken. En je moet same-interface traffic toestaan. Hiermee heb ik NAT reflection voor meerdere poorten prima in kunnen regelen.