Verkkoliikenne ohjautuu väärään porttiin (Arris TG2492s ja pfSense)

[Rensu]

Alustuksena että kyseinen kötöstys on toiminut useita vuosia, ensiksi Elisan ADSL-liittymällä ja myöhemmin samalla Arris TG2492s kaapelimodeemilla Telian verkossa. Ongelmat alkoivat kun kaapelinetti vaihtui Elisalle ja samalla Arrisin ohjelmisto päivittyi.

Eli kaapelimodeemista on kytketty kaksi verkkojohtoa reitittimeen (pfSense) CABLE ja CABLE_PUBL. CABLE liittynnän kautta menee kaikki normaali internet-liikenne ja CABLE_PUBL kautta WEB-palvelimen liikenne. Modeemi on sillattuna ja molemmat reitittimen liitynnät saavat omat julkiset IP:t. DDNS palvelimelle päivittyy CABLE_PUBL liitynnän ip normaalisti. Reititin tekee porttiohjauksen CABLE_PUBL porttien 80 ja 443 liikenteestä WEB-palvelimelle sisäverkon osoitteeseen 10.0.0.50.

Ongelma on, että WEB-palvelimeen ei saa yhteyttä kuin satunnaisesti. Voi olla että toimii 5 minuuttia ja sitten on taas hetken toimimatta. Palomuurin logeista selviää, että jostain syystä CABLE_PUBL osoitteeseen osoitetetut paketit tulevatkin CABLE liityntään ja reitittimen palomuuri estää ne sääntöjen mukaisesti. Onkohan tässä jokin oma verkkotekninen kämmi ja homma on toiminut ennen tuurilla vai sekoileeko tuo modeemi jotain?

 

[telcoM]

Tämä kuuluu sarjaan "on toiminut pelkällä tuurilla."
Netmaskilla /22 sekä 85.156.122.X että 85.156.120.X ovat samaa IP-segmenttiä, jonka alaraja on 85.156.122.0 ja yläraja 85.156.123.255.

Tästä seuraa että kaapelimodeemi ja/tai PFsense saattaa luulla että kumpaakin julkista IP-osoitetta voi käyttää kumman hyvänsä verkkoliitännän kautta (jos kaapelimodeemin TCP/IP ajuripino on toteutettu ns. weak host model-suunnitteluperiaatteella jota esim. Linux oletusarvoisesti käyttää). Palomuurilogit viittaavat juuri tähän suuntaan.

Juuri tämä ilmiö puraisee usein jos yhtä laitetta yritetään liittää kahdella eri verkkoliitännällä samaan verkkosegmenttiin.

Jos 85.156.120.X ja 85.156.122.X on tarkoitus olla eri verkkosegmenttejä, maskin pitäisi olla vähintään /23. Mutta olettaisin että maski tulee tässä yhteydentarjoajan DHCP-palvelusta, joten sitä ei voi vaihtaa itse. (Yhteydentarjoajan yhdyskäytävä (default gateway) on verkon jommassakummassa puolikkaassa, ja netmaskin kasvatus /23:een jakaisi verkkosegmentin kahtia, jolloin siitä toisesta puolikkaasta katsottuna yhdyskäytävä olisi verkon ulkopuolella, mikä on huono juttu.)

Voisiko PFsenseen määritellä niin että samalle fyysiselle verkkoliitännälle määriteltäisiin toinenkin IP-osoite DHCP:llä, vaikka ns. verkkoliitäntäaliaksena (alias interface)? Silloin ei tarvittaisi kuin yksi fyysinen kaapeli, ja palomuurisäännöt voisi tehdä niin että ensisijaisesta liitännästä normaali liikenne ja aliaksesta webbipalvelimen liikenne. Oleellista olisi jotenkin saada palomuurisäännöt toimimaan käytännössä IP-osoitteen eikä fyysisen verkkoliittimen mukaan.

 

[mikajh]

Ei noilla julkisilla IPv4-osoitteilla ole mitään merkitystä, voivat olla vaikka vierekkäisiä ja silti niitä voi käyttää portinohjauksissa täysin toisistaan riippumatta.
pfSense tekee oletuksena interfacet WAN, LAN, OPT1, OPT2, OPT3 jne. Ne voi nimetä sitten vaikka WAN1 (CABLE), LAN, WAN2 (CABLE_PUBL), DMZ.
Sitten Firewall - NAT interface WAN2_CABLE_PUBL NAT IP 10.0.0.50 (DMZ:ssa?).

Tuossa kuvassa kaikki on LAN jotain, mikä hieman häiritsee. Mutta mitä on määritetty palomuuriin, se jää aika epäselväksi.
LAN:iin sitten outgoing sääntö, että LAN:ista lähtevä liikenne menee WAN_CABLE:n kautta. Portinohjauksen vaatimat incoming WAN-säännöt pfSense tekee automaattisesti.

 

[Rensu]

Kiitoksia vastauksista.

Tämä kuuluu sarjaan "on toiminut pelkällä tuurilla."
Netmaskilla /22 sekä 85.156.122.X että 85.156.120.X ovat samaa IP-segmenttiä, jonka alaraja on 85.156.122.0 ja yläraja 85.156.123.255.

Tästä seuraa että kaapelimodeemi ja/tai PFsense saattaa luulla että kumpaakin julkista IP-osoitetta voi käyttää kumman hyvänsä verkkoliitännän kautta (jos kaapelimodeemin TCP/IP ajuripino on toteutettu ns. weak host model-suunnitteluperiaatteella jota esim. Linux oletusarvoisesti käyttää). Palomuurilogit viittaavat juuri tähän suuntaan.

Juuri tämä ilmiö puraisee usein jos yhtä laitetta yritetään liittää kahdella eri verkkoliitännällä samaan verkkosegmenttiin.

Jos 85.156.120.X ja 85.156.122.X on tarkoitus olla eri verkkosegmenttejä, maskin pitäisi olla vähintään /23. Mutta olettaisin että maski tulee tässä yhteydentarjoajan DHCP-palvelusta, joten sitä ei voi vaihtaa itse. (Yhteydentarjoajan yhdyskäytävä (default gateway) on verkon jommassakummassa puolikkaassa, ja netmaskin kasvatus /23:een jakaisi verkkosegmentin kahtia, jolloin siitä toisesta puolikkaasta katsottuna yhdyskäytävä olisi verkon ulkopuolella, mikä on huono juttu.)

Voisiko PFsenseen määritellä niin että samalle fyysiselle verkkoliitännälle määriteltäisiin toinenkin IP-osoite DHCP:llä, vaikka ns. verkkoliitäntäaliaksena (alias interface)? Silloin ei tarvittaisi kuin yksi fyysinen kaapeli, ja palomuurisäännöt voisi tehdä niin että ensisijaisesta liitännästä normaali liikenne ja aliaksesta webbipalvelimen liikenne. Oleellista olisi jotenkin saada palomuurisäännöt toimimaan käytännössä IP-osoitteen eikä fyysisen verkkoliittimen mukaan.

Tuota tässä pelkäsinkin. Maski tulee tosiaan palveluntarjoajan DHCP palvelimelta joten se on mitä on. PFsenseen ei voi tehdä verkkoliityntäaliaksia DHCP käytössä. Pitää tutustua onnistuuko tuo palomuurisääntöjen tekeminen IP-osoitteiden mukaan. Varma en ole, mutta mielestäni Telian yhteyden aikaan osoitteet oli eri verkoissa ja niillä oli luonnollisesti eri gateway. Tämä selittäisi miksi se ennen toimi ja nyt heitti pelaamasta.

Ei noilla julkisilla IPv4-osoitteilla ole mitään merkitystä, voivat olla vaikka vierekkäisiä ja silti niitä voi käyttää portinohjauksissa täysin toisistaan riippumatta.
pfSense tekee oletuksena interfacet WAN, LAN, OPT1, OPT2, OPT3 jne. Ne voi nimetä sitten vaikka WAN1 (CABLE), LAN, WAN2 (CABLE_PUBL), DMZ.
Sitten Firewall - NAT interface WAN2_CABLE_PUBL NAT IP 10.0.0.50 (DMZ:ssa?).

Tuossa kuvassa kaikki on LAN jotain, mikä hieman häiritsee. Mutta mitä on määritetty palomuuriin, se jää aika epäselväksi.
LAN:iin sitten outgoing sääntö, että LAN:ista lähtevä liikenne menee WAN_CABLE:n kautta. Portinohjauksen vaatimat incoming WAN-säännöt pfSense tekee automaattisesti.

Kuvaan jäi turhaan nuo modeemin LAN1 ja LAN2 tekstit, ne kuvaavat vain fyysisien liitäntöjen nimiä. PFsensessä on interfaceina CABLE, CABLE_PUBL ja LAN. Ja firewall NAT juurikin noin, eli CABLE_PUBL NAT PORT FORWARD 80 ja 443 IP 10.0.0.50. Mutta ongelma on siinä, että modeemi puskee CABLE_PUBL ip:n paketit CABLE interfaceen ja niille paketeille ei löydy sääntöjä.

Tuplasin nyt nuo port forwardit niin että siellä on ohjaukset molemmista interfaceista tuleville CABLE_PUBL ip:n paketeille:

• interface CABLE_PUBL, dest ip CABLE_PUBL
• interface CABLE, dest ip CABLE_PUBL

Tämä vaikuttaisi toimivan ainakin purkkavirityksenä.

 

[mikajh]

Onko CABLE_PUBL ja CABLE -interfaceilla eri mac-osoite? Kaksi julkista IPv4-osoitetta voisi olla samassakin fyysisessä pfSense-interfacessa käyttämällä Interfaces - Bridges -toimintoa, mutta kaksi fyysistä interfacea on helpompi.

EDIT: Jos pfSensen WAN-interfaceilla on eri mac niin kuin pitää, niin oletettavasti Arris ei toimi kytkimenä, joka tukee ARPia. Siinä tapauksessa ota toinen naru Arrisista kokonaan pois ja kytke toinen kunnolliseen kytkimeen. Sitten tämä kytkin kahdella piuhalla pfSensen WAN1 ja WAN2:een

 

[Rensu]

Onko CABLE_PUBL ja CABLE -interfaceilla eri mac-osoite? Kaksi julkista IPv4-osoitetta voisi olla samassakin fyysisessä pfSense-interfacessa käyttämällä Interfaces - Bridges -toimintoa, mutta kaksi fyysistä interfacea on helpompi.

EDIT: Jos pfSensen WAN-interfaceilla on eri mac niin kuin pitää, niin oletettavasti Arris ei toimi kytkimenä, joka tukee ARPia. Siinä tapauksessa ota toinen naru Arrisista kokonaan pois ja kytke toinen kunnolliseen kytkimeen. Sitten tämä kytkin kahdella piuhalla pfSensen WAN1 ja WAN2:een

Juu, on erit MAC-osoitteet. Tuo kytkimen väliin laittaminen todennäköisesti ratkaisisi ongelman.

Tuossa kun lueskelin PFsensen foorumia, niin alkaa tuntumaan siltä että tuo kaksi WAN yhteyttä samalla yhdyskäytävällä on "ei niin tuettu, eikä suositeltu toimintatapa". Esimerkiksi reititystaulussa on kaikien PFsenseen määriteltyjen DNS palvelimien interfacena igb3 = CABLE, vaikka DNS määrityksissä on 1.0.0.1 osoitteella CABLE_PUBL gatewaynä.

Destination	Gateway	Flags	Use	Mtu	Netif	Expire
default	85.156.120.1	UGS	335959	1500	igb3
1.0.0.1	85.156.120.1	UGHS	0	1500	igb3
8.8.4.4	85.156.120.1	UGHS	143896	1500	igb3
8.8.8.8	85.156.120.1	UGHS	143835	1500	igb3

Mutta vuorokauden homma on nyt toiminut tuolla purkkavirityksellä. Pitää jossain välissä kokeilla laittaa kytkin väliin ja ihmetellä mitä tapahtuu.