Login Connection



  • When I look at the state table (Diagnostics -> States) straight after PFSense firewall login I see a connection is shown in the state table to 208.23.73.93:443.  I can't seem to block this with the firewall rules.    Has anyone else seen this - might be connected with the ISP?

    J


  • Rebel Alliance Global Moderator

    That is a sprintlink IP.



  • So far as I can tell this connection only happens on login to PFSense interface,  and has only started happening since upgrade to release 2.4.3.  A packet capture includes the words  "netgate"  and "comodo".

    J



  • Ok, I should have dug a little deeper to find out about this address, failed to find any info on a quick initial try.

    Question now is, after the latest update, does PFSense call home when logging in to the web interface, and if this is related to update checking, etc, can this be disabled?

    J


  • Rebel Alliance Global Moderator

    in your state stable your showing pfsense make the connection, or something behind pfsense.  Is this state complete or in a wait state.  It doesn't answer ping, I do not get a syn,ack back on http or https.

    Then again I am not using sprint as my isp… Are you?




  • It's not something behind PFS, adding firewall rules does not stop this.    The connection is made when logging in to the PFS  WEB interface.  By the time that I can get to the state table it's showing wait, connection is over.  State table only shows this connection in wait and the computer (browser) connected to PFS  LAN connection  as established (no other traffic).

    My  ISP is not sprint.

    See my post above about calling home.


  • Rebel Alliance Global Moderator

    That is not pfsense calling home… You can connect to pfsense update site..  Where are you seeing something about netgate and comodo.

    What packages do you have installed?

    Whatever that IP is - its not answering on 80 or 443.. So whatever it is you think is going there isn't getting an answer.  Atleast I do not get an answer.

    Please post your states your seeing, and a copy of your package capture showing what you believe is netgate and comodo.  pcap is best so can open in wireshark.



  • After some digging around and whois,  I found the site IP address is connected to  Rubicon Communications, Austin TX.  I believe they are connected with Netgate and hence PFSense.

    The capture I took straight out of PFS  - I have not gone to a lot of trouble with it, its quite short.  I set PFS to do the capture, logged out and then in again, downloaded the capture to see what I got and opened in a text editor.  The words  netgate and comodo are in plain text.  Comodo will be present I suspect due to the port 443 connection.

    I only have the RRD summary package installed.

    I've convinced myself that this is PFS calling home,  adding firewall rules to block this IP does not stop the connection.

    J


  • Rebel Alliance Global Moderator

    if it was pfsense calling home then you would be able to connect to it on 443.. It doesn't answer SYN.. from testing to that IP..

    Where did you dig up that IP tied to rubicon?

    https://www.robtex.com/ip-lookup/208.23.73.93#records

    Update for pfsense would be a SRV record that ends up pointing to files00 or files01.netgate.com there is a firmware check as well..

    there are some firmware and ews records, etc. nothing that I see pointing to that IP.. or even that netblock.

    As example - here is IP that is checked by pfsense
    https://www.robtex.com/ip-lookup/162.208.119.40



  • Big ooops.

    The web address has a typo.  It should be 208.123.73.93:443

    Most sorry about this

    J.


  • Rebel Alliance Global Moderator

    Well that IP is netgate yes.

    ews.netgate.com resolves to that.

    ;; QUESTION SECTION:
    ;ews.netgate.com. IN A

    ;; ANSWER SECTION:
    ews.netgate.com. 2501 IN A 208.123.73.93

    ;; AUTHORITY SECTION:
    netgate.com. 2501 IN NS ns2.netgate.com.
    netgate.com. 2501 IN NS ns1.netgate.com.

    ;; ADDITIONAL SECTION:
    ns1.netgate.com. 2501 IN A 192.207.126.6
    ns2.netgate.com. 2501 IN A 162.208.119.38
    ns1.netgate.com. 2501 IN AAAA 2610:160:11:3::6
    ns2.netgate.com. 2501 IN AAAA 2610:1c1:3::108

    Do you have the support wiget on your page?

    https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/widgets/widgets/netgate_services_and_support.widget.php

    
    $supportfile = "/var/db/support.json";
    $idfile = "/var/db/uniqueid";
    $FQDN = "https://ews.netgate.com/support";
    $refreshinterval = (24 * 3600);	// 24 hours
    
    


  • By page  I guess you mean the dashboard screen.

    Support widget is shown as an option to add if I click the + sign at the top but is not actually present or active on the dashboard.

    The "connection" happens every time I open the browser on the PFS web login screen.

    States as below:-

    WAN tcp xx.xx.xx.xx:xxxx -> 208.123.73.93:443 FIN_WAIT_2:FIN_WAIT_2 14 / 12 2 KiB / 7 KiB
    LAN tcp 192.168.x.xxx:xxxx -> 208.123.73.70:443 FIN_WAIT_2:FIN_WAIT_2 40 / 42 11 KiB / 31 KiB

    ews.netgate.com is in the capture file.

    J



  • IIRC pfSense is checking/updating the copyright notice when you login, this could be the reason for that connection. See: https://github.com/pfsense/pfsense/blob/master/src/etc/inc/copyget.inc



  • Thanks for that info.

    My guess,  now,  is that you are correct.  However, my first thought on seeing the connection was that I had managed to get a virus,  . … somewhere.  I don't think this ever happened with previous PFS versions, and there's nothing in the release notes.

    It would be nice if it could happen only with the monthly bogon update, such that when checking for "no traffic" after a known period of wan inactivity there really is none.  I haven't checked, but if this traffic shows in the interface statistics log widget on my dashboard,  and if I know the WAN traffic  figures when WAN activity stops at night and then check the figure again in the morning there will be some traffic shown.  My first thought would have been virus.

    J



  • Found this thread when searching for 208.123.73.93 as it showed up in the fw log and wasn't expecting it.
    A quick float block rule with logging shows it tries twice and gives up.



  • For systems behind a firewall, this add a sensitive lag when logiing in or going to the dashboard.
    It would be nice to make that call not as often as the page is loaded.