SPF functionering met 1 actief IP en non-actief failover IP

[marcop82]

Edit: dus geen SPF record issue, want probleem is met sommige binnenkomende mails.

Op werk hebben we twee WAN lijnen van verschillende providers met elk een eigen vast IP adres. Router, modems en firewall vallen onder beheer van een externe partner. Het probleem is dat ik niet zeker ben dat de opstelling werkt met onze SPF record die naar het IP van WAN1 verwijst, evenals het IP van WAN2.

Het probleem is dat de firewall (ivm. VPN configuratie verschillende sites, router heeft mogelijk wel beide actief) blijkbaar niet toelaat beide WANs actief te hebben, dus zolang WAN1 actief is, komt er geen verkeer binnen op WAN2, zelfs nog geen ping. Zodra WAN1 onderbroken wordt, gaat WAN2 wel correct functioneren. Dit is volgens onze partner de eigenschap van de voorziening van de firewall.

Spul dat we gebruiken:
Firewall: FortiGate 200B
Router: Cisco 891F

Ik vermoed dat twee ip4 vermeldingen in de SPF record ofwel via round-robin werken, ofwel dat deze door verschillende servers anders geïnterpreteerd worden (bij de ene wordt het eerste IP gebruikt, bij de ander het laatste IP), maar ik vind hier geen informatie over terug en al zeker niet hoe we bovenstaande kunnen oplossen zonder grove wijzigingen aan ons netwerk.

[ Voor 3% gewijzigd door marcop82 op 28-07-2016 11:22 ]

[Kees]

Ik denk dat je wat dingen doorelkaar haalt.

SPF records definieren welke IP's mail met dat domein als afzender mogen sturen. Een mailserver hoeft dus alleen maar te controleren of de mailserver waar hij op dat moment een connectie mee heeft die mail mag versturen. Hij hoeft de andere ip's niet te controleren (gelukkig maar, want je mag ook gerust een ipv6 /32 erin gooien, dan zou die mailserver meer adressen moeten checken dan dat er atomen in het universum zijn).

Dus die twee ip4 meldingen in je SPF record zeggen alleen maar: Jan en Piet mogen dit doen. En op het moment dat Jan dan iets probeert te doen dan gaat niemand vragen 'maar waar is Piet?'.

[PerfectPC]

Wat Kees zei dus.

Loop je tegen problemen aan?

[marcop82]

Ah correct, daar maak ik inderdaad een denkfout. We hebben een probleem met binnenkomende mail dat waar sommige partners ons geen mail kunnen sturen.

Een uitloopje van dnsstuff.com:

Overall Results:
0 FAIL
4 WARNING
29 PASS
5 INFO

De fails:

Parent zone provides NS records
Parent zone does not provide glue for nameservers, which will cause delays in resolving your domain name. The following nameserver addresses were not provided by the parent 'glue' and had to be looked up individually. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of "ns1.example.org" for the domain "example.com"). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain.

SOA field check
One or more SOA fields are outside recommended ranges. Values that are out of specifications could cause delays in record updates or unnecessary network traffic. The SOA fields out of range are:

serial | ************* SERIAL - we check that your serial number matches the recommended format found in RFC1912 section 2.2.

MX records check
Only one MX record exists within the zone. This is ok, but it is a better practice to have at least two mail servers operating on a domain, to ensure more reliable mail deliverability.

SMTP greeting
Malformed greeting or no A records found matching banner text for following servers, and banner is not an address literal. RFC5321 requires one or the other (should not be a CNAME). If this is not set correctly, some mail platforms will reject or delay mail from you, and can cause hard to diagnose issues with deliverability.

[PerfectPC]

Enkel die laatste is problematisch.
Je moet zorgen dat je mailserver een deftige greeting heeft (helo of ehlo). Bv: mailserver.domain.tld
En er moet ook een a record bestaan voor deze naam.

[Rolfie]

Je hebt 2 external IP's (ivm 2 WAN's) maar je MX record verwijst zo te zien maar naar 1 record.

PerfectPC schreef op donderdag 28 juli 2016 @ 11:26:
Enkel die laatste is problematisch.
Je moet zorgen dat je mailserver een deftige greeting heeft (helo of ehlo). Bv: mailserver.domain.tld
En er moet ook een a record bestaan voor deze naam.

Dit kan, maar ervaring is dat dit niet echt uit maakt. Het kan het probleem zijn. Maar de vraag is of dit het is. Ik zou eerst bij de partij die het probleem heeft, eens na vragen wat voor een foutmelding men exact krijgt (NDR of SMTP logfiles)

[marcop82]

PerfectPC schreef op donderdag 28 juli 2016 @ 11:26:
Enkel die laatste is problematisch.
Je moet zorgen dat je mailserver een deftige greeting heeft (helo of ehlo). Bv: mailserver.domain.tld
En er moet ook een a record bestaan voor deze naam.

Dit doet ie ook, maar wel ons intern adres (mailserver.domein.com) in plaats van ons extern adres (mail.domein.com).

Bij de HELO/EHLO krijgen we dus onze interne mail server hostname te zien. Dit was al zo toen ik hier kwam, ik weet niet of dit positief of negatief is, daarvoor is mijn Exchange kennis niet toereikend.

Enerzijds kan ik dus de Receive Connector aanpassen naar ons extern adres, die intern ook in de DNS is opgenomen. Anderzijds kan ik ons intern adres ook (laten) toevoegen aan onze provider zijn DNS records.

[marcop82]

Rolfie schreef op donderdag 28 juli 2016 @ 11:46:
Je hebt 2 external IP's (ivm 2 WAN's) maar je MX record verwijst zo te zien maar naar 1 record.

Klopt, dit hadden we al eens geprobeerd en toen ging ie gezellig "round-robinnen" (ook met andere pref) tussen WAN1 en WAN2, terwijl verkeer verstuurd naar WAN2 dus niet doorkwam omdat die non-actief was, waardoor de helft van onze externe receiving mails rejected werden met een paar dagen vertraging.

Door enkel de actieve lijn zijn IP adres in de MX record te steken, zorgen we ervoor dat mail wel consistent (dachten we) binnenkomt en bij downtime, blijven mails meestal een paar dagen in de lucht voor retry voordat ze teruggestuurd worden.

code:

Name             Pref   Addresses      Port 25  DNS      Open Relay     SPF     RBLs
mail.domein.com  10     81.82.222.63   UP       Matched  OK             pass    1/53/37

[CyBeR]

Mail wordt niet geround-robined over MX'en als je verschillende preferences gebruikt. Wel is het zo dat veel spammers met een secondary mx verbinding maken in de hoop dat die minder streng of niet spamfiltert.

[marcop82]

Misschien dat de provider het verknoeid had, want het leek logisch verschillende preferences te gebruiken om dat probleem te vermijden.

[ Voor 12% gewijzigd door marcop82 op 28-07-2016 15:26 ]

[Rolfie]

marcop82 schreef op donderdag 28 juli 2016 @ 12:05:
Klopt, dit hadden we al eens geprobeerd en toen ging ie gezellig "round-robinnen" (ook met andere pref) tussen WAN1 en WAN2, terwijl verkeer verstuurd naar WAN2 dus niet doorkwam omdat die non-actief was, waardoor de helft van onze externe receiving mails rejected werden met een paar dagen vertraging.

Klinkt eerder als een foute configuratie. Want dit zou zo niet moeten werken. Als het de zelfde prio heeft, kan dit wel in theorie gebeuren.

[CyBeR]

Niet "in theorie", als ze dezelfde prio hebben dan komt mail willekeurig (niet round-robin, technisch gezien) bij de twee IP's aan. Maar dat gezegd is 't wel zo dat een onbereikbare host 1, betekent dat host 2 ook direct geprobeerd wordt.

[knutsel smurf]

Hoeveel public adressen heb je in totaal?

Kan je de router en firewall zo configureren dat je 1 extern adres hebt voor alles en dat de router de load balancing doet ipv dns het op te laten lossen?

Snap dat het door een externe partij beheerd wordt maar overleg is misschien de beste oplossing.

[marcop82]

Alvast bedankt om mee te helpen denken, ik probeer zelf de oorzaak van het probleem te begrijpen zodat de provider ons geen oplossing voorziet die uiteindelijk en achteraf slecht werkt.

Rolfie schreef op donderdag 28 juli 2016 @ 16:52:
[...]


Klinkt eerder als een foute configuratie. Want dit zou zo niet moeten werken. Als het de zelfde prio heeft, kan dit wel in theorie gebeuren.

Dat leek mij dus ook maar dan wil het zeggen dat onze provider nog niet eens personeel heeft dat een DNS kan beheren. Ik kan dat ook wel niet, maar ik pretendeer dan ook niet, voor mijn werkgever moet ik dat ook niet.

CyBeR schreef op donderdag 28 juli 2016 @ 16:59:
Niet "in theorie", als ze dezelfde prio hebben dan komt mail willekeurig (niet round-robin, technisch gezien) bij de twee IP's aan. Maar dat gezegd is 't wel zo dat een onbereikbare host 1, betekent dat host 2 ook direct geprobeerd wordt.

Zou dit misschien toch fout gaan als het WAN1 én WAN2 IP adres bestaat, maar WAN2 geen trafiek doorlaat voorbij de firewall ? Ik probeer zelf de situatie te snappen want onze provider komt niet met oplossingen voor de boeg die ons geen zekerheden op succes kunnen bieden.

knutsel smurf schreef op donderdag 28 juli 2016 @ 21:46:
Hoeveel public adressen heb je in totaal?

Twee vaste, publieke WAN IP-adressen op die locatie, één vast intern gateway IP-adres achter de firewall.

Kan je de router en firewall zo configureren dat je 1 extern adres hebt voor alles en dat de router de load balancing doet ipv dns het op te laten lossen?

Dat lijkt me dus ook maar ik weet niet hoe dit doorgaans aangepakt wordt en onze provider komt zelf niet met een oplossing hiervoor naar voren. Aangezien ik dat 1 adres niet als een extra SPOF wil inrichten in plaats van juist meer redundantie te voorzien door twee internetlijnen van twee verschillende media en providers.

[ Voor 4% gewijzigd door marcop82 op 29-07-2016 09:35 ]

[PerfectPC]

knutsel smurf schreef op donderdag 28 juli 2016 @ 21:46:
Hoeveel public adressen heb je in totaal?

Kan je de router en firewall zo configureren dat je 1 extern adres hebt voor alles en dat de router de load balancing doet ipv dns het op te laten lossen?

Snap dat het door een externe partij beheerd wordt maar overleg is misschien de beste oplossing.

Daarvoor heb je PI address space nodig zodat je kan multihomen via bgp. Lijkt me overkill voor deze situatie.

[Rolfie]

marcop82 schreef op vrijdag 29 juli 2016 @ 09:34:
.....

Ik denk tijd voor een andere provider, of ICT beheerders die verstand van zaken hebben. Dit moet namelijk gewoon kunnen op een goede firewall.

[marcop82]

Daar zijn we ook mee bezig, maar dat zal volgende week of volgende maand niet rond zijn

[knutsel smurf]

PerfectPC schreef op vrijdag 29 juli 2016 @ 09:43:
[...]


Daarvoor heb je PI address space nodig zodat je kan multihomen via bgp. Lijkt me overkill voor deze situatie.

Weet niet of het overkill is vaak is het maar een paar tientjes per maand duurder en aan een /30 heb je voldoende.

Een wan met vpn's vind ik net niets

[PerfectPC]

Je moet minstens een /24 advertisen om niet gefilterd te worden in de dfz

[CyBeR]

En success met daar aan komen.

[CAPSLOCK2000]

* CAPSLOCK2000 komt op z'n stokpaardje aangereden

IPv6! IPv4 adresruimte ga je niet meer krijgen zonder er flink voor te betalen maar IPv6 is wel goed te doen. Nu is de wereld nog niet ver genoeg om IPv6-only te draaien, maar met mail kom je een heel eind. Tientallen procenten van internet heeft IPv6 op z'n mailserver, waaronder de grootste spelers zoals Gmail en Microsoft. Daarmee heb je een flink deel van de markt gedekt.
Bij een storing valt je IPv4 dan misschien wel uit maar via IPv6 kun je nog steeds mailen met een groot deel van je contacten. Niet perfect, maar beter dan niks.

[marcop82]

Buiten het compleet shift-deleten van onze huidige WAN opstelling, nog andere suggesties ?

[Heineken01]

Een cloud spamfilter afnemen, deze accepteert de ontvangende email en je kan daar de ip's op geven waar de gefilterde email op moet worden afgeleverd. De cloudspamfilter luistert niet zo nauw naar instellingen aan de ontvangende kant.

[Powermage]

Je kan kiezen email via een cloud spamfilter te doen, op onze clusters kunnen we gewoon 2 IP's opgeven, is de ene onbereikbaar probeert hij de andere.

Maargoed, 2 goede MX records naar beide ip adressen moet dit ook gewoon goed laten werken, dat is nu net t hele idee van die dingen.

[marcop82]

Bedankt ik ga hiermee verder kunnen. De cloud spamfilter is een interessante optie !