Verbinden lukt alleen na ping

[thegve]

Ik heb een raar probleem wat al een tijdje speelt. Bij mijn werkgever werken we vanuit 2 datacentra. Een rack in een datacenter A op eigen hardware waarin back-up, monitoring en R&D zit, en een gehuurde VMWare vCloud omgeving voor alle productiemeuk. Tussen deze 2 datacentra is een dedicated fiber verbinding. Ik heb de router/firewall bij DC B gedaan. Deze heeft een poort in het netwerk van DC A waardoor deze rechtstreeks daar in de switch kan.



Nu heb ik het probleem dat een verbinding van een server bij DC B naar een server bij DC A alleen lukt nadat ik eerst een ping heb gedaan. Bij een apt-cacher ziet dat er als volgt uit:

code:

root@server_dc_b:/etc/apt/apt.conf.d# apt-get -y update
0% [Connecting to 192.168.1.2 (192.168.1.2)] [Connecting to 192.168.1.2 (192.168.1.2)] [Connecting to 192.168.1.2 (192.168.1.2)]^C
root@server_dc_b:/etc/apt/apt.conf.d# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_req=1 ttl=62 time=1.62 ms
^C
--- 192.168.1.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.625/1.625/1.625/0.000 ms
root@server_dc_b:/etc/apt/apt.conf.d# apt-get -y update
Get:1 http://ftp.nl.debian.org wheezy Release.gpg [1,655 B]
Get:2 http://ftp.nl.debian.org wheezy-updates Release.gpg [836 B]

IP adressen/hostnames zijn vervangen overigens.

Tijdens debuggen lukte het mij om middels 'nmap -P0' (poort test, zonder eerst een ping te doen), te verbinden tot en met 192.168.1.3.

Ik ben verre van een netwerk expert, maar mijn gevoel zegt mij dat dit een ARP probleem is.

[plizz]

Kan je de ARP tabel oproepen voor ping en vergelijk na de ping?

[thegve]

Even een testje gedaan met 2 servers binnen DC B. Voor/na ping blijft de ARP table gelijk, bevat alleen zichzelf en de router.
Na pingen werkt het wel op deze server, maar op de tweede server werkt het nog steeds niet, deze moet dus zelf de ping truck uitvoeren.
Ik begin zolangzamerhand ook een beetje te twijfelen aan mijn eigen arp theorie, vanwege deze tests.

[plizz]

Hoe is die Pfsense ingericht? Als Stateful of stateless firewall? Het lijkt of de ping, van B naar A, de sessie opzetten van A naar B. Dus hierdoor kan B naar A.

[Ben(V)]

Toch vreemd, na een ping zou de arp tabel van de server in DC B toch op z'n minst het mac adres van de server in DC A die gepinged is moeten bevattten.

Tenzij je te lang gewacht hebt, ik dacht dat de arp timeout voor windows servers 2 minuten was.

Om te zien of het iets met arp te maken heeft zou je op een server in DC B een static arp entry kunnen maken van een Server in DC A met het commando

arp -sip_addressmac_address

[ Voor 52% gewijzigd door Ben(V) op 23-03-2015 16:23 ]

[plizz]

Ben(V) schreef op maandag 23 maart 2015 @ 16:19:
Toch vreemd, na een ping zou de arp tabel van de server in DC B toch op z'n minst het mac adres van de server in DC A die gepinged is moeten bevatten.

[...]

Ik denk dat je de MAC adres van PfSense bedoeld omdat de gateway is.

[thegve]

De firewall rule is aangemaakt met 'keep state', dit is de standaard instelling.

code:

State types – pfSense offers multiple options for state handling.

    Keep state – Works with all protocols. Default for all rules.
    Modulate state – Works only with TCP. pfSense will generate strong Initial Sequence Numbers (ISNs) on behalf of the host.
    Synproxy state – Proxies incoming TCP connections to help protect servers from spoofed TCP SYN floods. This option includes the functionality of keep state and modulate state combined.
    None – Do not keep any state entries for this traffic. This is very rarely desirable, but is available because it can be useful under some limited circumstances.

Ik heb voor de zekerheid een poging gedaan om het mac adres statisch toe te voegen bij DC B, maar in principe zou dit niet moeten helpen, want ARP werkt in principe binnen 1 netwerk volgens mij.

code:

man arp
...
arp [-v] [-H type] [-i if] -s hostname hw_addr [temp]
<knip>
arp -s 192.168.1.2 ab:cd:ef:12:34
SIOCSARP: Network is unreachable

[plizz]

Het klopt, ARP werkt alleen binnen 1 netwerk. Pfsense is stateful volgens hun wiki. Hoe is die firewall geconfigureerd?

[Ben(V)]

Oeps iets te snel gekeken. Dacht dat DC A en DC B in hetzelfde subnet zaten.
Toch moet dan het macadres van die pfsense erin staan.
Of bedoelde je dat met het adres van je router?

[thegve]

De pfSense is de router inderdaad. Deze routeert tussen een lan in DC A en een lan in DC B.

@plizz. Wat wil je precies weten van de firewall configuratie?

Uiteindelijk zijn de rules wel goed dus, anders zou er helemaal geen traffic zijn.

[plizz]

Ik zie dat apt-get TCP poort 80 gebruikt, dus http. Is er een firewall regel outbound DC B die TCP poort 80 toelaat? Zo ja, dan kan het aan iets anders liggen.

[thegve]

Apt heeft een proxy ingesteld staan naar de apt-cacher server in het andere datacentre. Deze gaat via de standaard apt-cacher poort 3142.
Maar dit staat dus per definitie goed, anders had het ook niet gewerkt na een ping.