Static Configuration won't work - Ideas where to look?



  • I just setup a new VMWARE pfsense machine. I cannot for the life of me get my WAN static IP configured. I have DHCP configured for the internal LAN. When the WAN is configured for DHCP the internet connection works. When I attempt to change WAN DHCP to my static configuration it loses internet connectivity. Here is my configuration:

    WAN Static Configuration:
    This configuration worked perfect on the Dlink router that it is replacing and a static configuration on my laptop.

    Comcast -> SMC8014 -> pfsense WAN Nic -> pfsense Firewall -> pfsense LAN Nic -> Internal LAN Switch

    IP Configuration:
    WAN Static IP - 75.XXX.79.144
    Subnet Mask - 255.255.255.0
    Gateway - 75.XXX.79.146

    DNS Primary - 75.75.75.75
    DNS Secondary - 75.75.76.76

    When I have the Static WAN configured I can ping google.com from WAN and LAN interface in the webconfigurator diagnostics. But I cannot ping from the computers that have received DHCP addresses from the LAN interface. Please help I have to get this working where I can I begin to look.



  • @natelabo:

    I cannot ping from the computers that have received DHCP addresses from the LAN interface.

    You can help me help you by providing more details, especially more details than "cannot ping". The ping response is almost always more informative than "cannot ping". Please provide the ping command and response for the following:

    • ping to name of pfSense box

    • ping to IP address of pfSense LAN IP address

    • ping to www.google.com

    • ping to 8.8.8.8



  • First guess, you don't have a gateway chosen under Interfaces>WAN.



  • I will get the information for you in just on sec… Just did a complete reinstall...



  • @wallabybob:

    • ping to name of pfSense box

    • ping to IP address of pfSense LAN IP address

    • ping to www.google.com

    • ping to 8.8.8.8

    C:\Users\nate>ping pfSense.private
    
    Pinging pfSense.private [192.168.0.1] with 32 bytes of data:
    Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
    Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
    Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
    Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
    
    Ping statistics for 192.168.0.1:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 0ms, Average = 0ms
    
    C:\Users\nate>ping 192.168.0.1
    
    Pinging 192.168.0.1 with 32 bytes of data:
    Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
    Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
    Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
    Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
    
    Ping statistics for 192.168.0.1:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 0ms, Average = 0ms
    
    C:\Users\nate>ping www.google.com
    
    Pinging www.google.com [74.125.225.82] with 32 bytes of data:
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.
    
    Ping statistics for 74.125.225.82:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
    
    C:\Users\nate>ping 8.8.8.8
    
    Pinging 8.8.8.8 with 32 bytes of data:
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.
    
    Ping statistics for 8.8.8.8:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
    
    


  • @cmb:

    First guess, you don't have a gateway chosen under Interfaces>WAN.




  • In Services:DHCP Server, Gateway should be blank. Then it will automatically give clients the pfSense LAN address as the gateway.
    (If you have put something like the WAN Gateway address in there, then the clients will have trouble, as they can't directly reach the WAN Gateway address.)



  • @phil.davis:

    In Services:DHCP Server, Gateway should be blank. Then it will automatically give clients the pfSense LAN address as the gateway.
    (If you have put something like the WAN Gateway address in there, then the clients will have trouble, as they can't directly reach the WAN Gateway address.)

    I have not modified any default settings. I have run the setup wizard and changed from DHCP to static configuration on the WAN interface. Nothing else has been changed.






  • I HAVE $25 THAT I WILL PAY TO WHOEVER HELPS ME SOLVES THIS! DESPERATE THIS IS A PRODUCTION MACHINE I HAVE GOT TO GET THIS WORKING



  • @natelabo:

    I have run the setup wizard and changed from DHCP to static configuration on the WAN interface. Nothing else has been changed.

    That would suggest you haven't given a DNS server or a default gateway, both of which are normally supplied by DHCP.

    Your ISP apparently provides a DHCP server to your WAN interface. Why not use it to get the minimum three configuration items (IP address, IP address of DNS, IP address of default gateway) rather than having to maintain them all yourself?

    Edit:
    I just realised @natelabo:

    changed from DHCP to static configuration

    might have meant you disabled DHCP server on the WAN interface (for some reason you posted a screen shot showing DHCP server on WAN disabled) but I initially thought you meant you had changed the WAN interface type (on Interfaces -> WAN) from DHCP to Static



  • Confirm that your client has actually got good settings from DHCP:

    ipconfig /all

    Ethernet adapter Local Area Connection:
    
       Connection-specific DNS Suffix  . : localdomain
       Description . . . . . . . . . . . : Intel(R) 82577LC Gigabit Network Connecti
    on
       Physical Address. . . . . . . . . : 1C-C1-DE-BC-5D-DC
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::3062:b201:f6bc:21a7%13(Preferred)
       IPv4 Address. . . . . . . . . . . : 10.49.46.208(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Lease Obtained. . . . . . . . . . : Thursday, 4 October 2012 7:09:48 AM
       Lease Expires . . . . . . . . . . : Thursday, 4 October 2012 10:09:48 AM
       Default Gateway . . . . . . . . . : 10.49.46.1
       DHCP Server . . . . . . . . . . . : 10.49.46.1
       DHCPv6 IAID . . . . . . . . . . . : 287097310
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-15-FE-C3-63-1C-C1-DE-BC-5D-DC
    
       DNS Servers . . . . . . . . . . . : 10.49.46.1
       NetBIOS over Tcpip. . . . . . . . : Enabled
    
    

    The client interface in use should normally have Default Gateway, DHCP Server and DNS Servers all with the same IP address of the pfSense router, in a simple LAN with 1 router network.
    Then try:

    tracert 8.8.8.8
    The first hop reported should be the IP address of your pfSense router, then the gateway of your ISP, then off to lots of hops in Internet-land.



  • @wallabybob:

    That would suggest you haven't given a DNS server or a default gateway, both of which are normally supplied by DHCP.

    Your ISP apparently provides a DHCP server to your WAN interface. Why not use it to get the minimum three configuration items (IP address, IP address of DNS, IP address of default gateway) rather than having to maintain them all yourself?

    I setup DNS servers in the setup wizard they also appear in the general settings. I set up the default gateway in the static setup portion of the setup wizard. The router is an SMC8014 for use on comcast biz class service. DHCP is offered but you can't access the static IP's. To bind the firewall to a static IP you must manually setup and the router passes it through.

    @wallabybob:

    might have meant you disabled DHCP server on the WAN interface (for some reason you posted a screen shot showing DHCP server on WAN disabled) but I initially thought you meant you had changed the WAN interface type (on Interfaces -> WAN) from DHCP to Static

    I'm confused I did mean that I swapped Interfaces->WAN from DHCP to Static. But in my Services: DHCP Server the "Enable DHCP Service on WAN Interface" is unchecked. DHCP service is enabled on the LAN interface. Is DHCP supposed to be setup on the WAN interface?



  • @phil.davis:

    Confirm that your client has actually got good settings from DHCP:

    ipconfig /all

    Ethernet adapter Local Area Connection:
    
       Connection-specific DNS Suffix  . : private
       Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
       Physical Address. . . . . . . . . : 00-24-BE-DD-03-F2
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::19cd:97cd:fe09:94ac%13(Preferred)
       IPv4 Address. . . . . . . . . . . : 192.168.0.200(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Lease Obtained. . . . . . . . . . : Wednesday, October 03, 2012 11:26:01 PM
       Lease Expires . . . . . . . . . . : Thursday, October 04, 2012 1:40:55 AM
       Default Gateway . . . . . . . . . : 192.168.0.1
       DHCP Server . . . . . . . . . . . : 192.168.0.1
       DHCPv6 IAID . . . . . . . . . . . : 285222078
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-15-CA-22-B3-00-24-BE-DD-03-F2
    
       DNS Servers . . . . . . . . . . . : 192.168.0.1
       NetBIOS over Tcpip. . . . . . . . : Enabled
    
    


  • @phil.davis:

    Then try:

    tracert 8.8.8.8
    The first hop reported should be the IP address of your pfSense router, then the gateway of your ISP, then off to lots of hops in Internet-land.

    C:\Users\nate>tracert 8.8.8.8
    
    Tracing route to google-public-dns-a.google.com [8.8.8.8]
    over a maximum of 30 hops:
    
      1     2 ms    <1 ms    <1 ms  pfsense.private [192.168.0.1]
      2     *        *        *     Request timed out.
      3     *        *        *     Request timed out.
      4     *        *        *     Request timed out.
      5     *        *        *     Request timed out.
      6     *        *        *     Request timed out.
      7     *        *        *     Request timed out.
      8     *        *        *     Request timed out.
      9     *        *        *     Request timed out.
     10     *        *        *     Request timed out.
     11     *        *        *     Request timed out.
     12     *        *        *     Request timed out.
     13  ^C
    


  • I can't believe that Comcast is putting that modem in true bridge mode for you.

    When you set up your WAN for DHCP what address does it get?



  • I'm confused I did mean that I swapped Interfaces->WAN from DHCP to Static. But in my Services: DHCP Server the "Enable DHCP Service on WAN Interface" is unchecked. DHCP service is enabled on the LAN interface. Is DHCP supposed to be setup on the WAN interface?

    That is correct. The pfSense DHCP Server is enabled on LAN, to give DHCP to the LAN clients (your PC etc). The WAN has a DHCP client only, which asks for DHCP network settings from a DHCP Server that your ISP provides.
    Your LAN client PC network settings look fine - it goes to your pfSense for all network stuff - gateway, DHCP and DNS.
    The traceroute goes to your pfSense then after that goes nowhere, presumably pfSense does not have a useful/valid default route.
    The issue is presumably somewhere in getting useful DHCP settings on WAN from the ISP DHCP server.
    What does Status:Interfaces show for WAN?
    What does Diagnostics:Routes show for the default route?



  • @chpalmer:

    I can't believe that Comcast is putting that modem in true bridge mode for you.

    When you set up your WAN for DHCP what address does it get?

    I'm a little confused I have tested this setup with a 2 low grade routers. Both routers can access WAN through the assigned Static IP and pass the connection to internal LAN. It is definately something with the pf box. It is not passing the packets? to the LAN.

    The SMC box by default is setup to apply 10.1.10.X addresses to hardware that is looking for DHCP. When I use DHCP on the pf box it receives a DHCP address of 10.1.10.X and a gateway address of 10.1.10.1. WAN works on anything given a DHCP address on the internal LAN from the pf box. It just won't pass when configured with a Static IP.



  • Comcast business does not allow static ips past the gateway device in the same manner as many other ISP's do.  Ive fought with them over this in the past. The only true bridge modem they will allow is a Motorola 6000 series and they wont let you use it if you have a static IP address.

    I believe in order to use your static IP your gonna need to leave the primary WAN as DHCP and use a VIP for the static.  I wont use Comcast anywhere I need a static and have been lucky enough so far to have another solution available at those locations.

    Did Comcast tech support provide you with instructions or any kind of direction?

    If you set the WAN of any of your other routers up as DHCP they get a 10.x.x.x address, correct?

    Unless Comcast has changed things in the last 6 mos. this is the way they do things.



  • @phil.davis:

    The traceroute goes to your pfSense then after that goes nowhere, presumably pfSense does not have a useful/valid default route.
    The issue is presumably somewhere in getting useful DHCP settings on WAN from the ISP DHCP server.
    What does Status:Interfaces show for WAN?
    What does Diagnostics:Routes show for the default route?






  • Okay just noticed this…

    Gateway Status: Offline








  • @chpalmer:

    Comcast business does not allow static ips past the gateway device in the same manner as many other ISP's do.  Ive fought with them over this in the past. The only true bridge modem they will allow is a Motorola 6000 series and they wont let you use it if you have a static IP address.

    I believe in order to use your static IP your gonna need to leave the primary WAN as DHCP and use a VIP for the static.  I wont use Comcast anywhere I need a static and have been lucky enough so far to have another solution available at those locations.

    Did Comcast tech support provide you with instructions or any kind of direction?

    If you set the WAN of any of your other routers up as DHCP they get a 10.x.x.x address, correct?

    Unless Comcast has changed things in the last 6 mos. this is the way they do things.

    This is a whole another discussion… and yes I can't stand the confusing setup of Comcast Routers for Biz Class. But you select two options and the router when faced with device presenting an external IP completely bypasses the router itself. As I stated the low grade routers work perfectly fine when configured with the exact static information that I am using on the pf box. Also yes this is how Comcast tells you to do this. I have a cPanel sever currently working on this router/connection setup the same way... Obviously different Static IP.



  • Gateway Status: Offline

    I guess that the ISP Gateway does not respond to ping. So pfSense thinks that the WAN is down (no response from the Monitor IP).
    Edit the Gateway settings and put in a Monitor IP of something real out in Internet-land that should always be up and respond to ping - I use 8.8.8.8 (Google DNS address). If that doesn't get you joy, then check the tickbox "Disable Gateway Monitoring" - pfSense will then always try to use the WAN interface, it won't appear "down".
    If you don't have multi-WANs available on the pfSense box, then there is no real benefit in monitoring the only WAN Gateway and having it declared "down".



  • Is your configured gateway (75.x.79.146) in the same subnet as the static IP you configured?

    Where is the machine with this IP address? Is it your SMC modem?

    If I recall correctly, some operating systems will  talk directly to systems on the same LAN which aren't in the same subnet but FreeBSD takes a stricter view. So, for example, if your pfSense WAN interface has IP address 75.x.80.10/24 then pfSense won't talk directly to 75.x.79.156 because the two interfaces are in different subnets. I believe I have seen reports that Linux and/or Windows aren't so strict and that might explain why the two "low end" routers you mentioned are able to work in your configuration.



  • I am calling it quits… After a lengthy conversation with a Comcast tech I apparently using a hidden static IP that I am not supposed to have access to. I don't know why I have access with the low end routers and can't get it with pfSense. I don't know how I even originally found it. It would be nice to figure it out because it would save me the money of adding 3 extra unneeded Statics. But I will call Comcast tomorrow and add additional IP's.  :-\

    Thanks to all that attempted to help with my issue...


  • Netgate Administrator

    If you decide to try again I would try what phil.davis suggested above. Disable gateway monitoring or change the IP being monitored.

    Also it doesn't look like you ran any ping tests from the pfSense console. This would determine if it was a routing problem or something upstream.

    Steve



  • @stephenw10:

    If you decide to try again I would try what phil.davis suggested above. Disable gateway monitoring or change the IP being monitored.

    Also it doesn't look like you ran any ping tests from the pfSense console. This would determine if it was a routing problem or something upstream.

    Steve

    Well I'm still here… I got ticked off because I want to solve this. I have set the monitoring to watch 8.8.8.8. The status is now saying online but I still have no connection on my internal LAN devices.

    I have run almost every test on the webconfigurator available. Nothing fails! It has been like this since the beginning. nslookup = good, ping LAN and WAN (google, ebay, and 8.8.8.8) = all good, tracert (google, ebay) = all working. Still my devices on internal LAN cannot resolve past the pfsense gateway address (192.168.0.1) as shown in the picture way earlier.


  • Netgate Administrator

    Ok so connectivity is good on pfsense WAN and LAN clients can connect the pfSense LAN side. In which case routing is not working or traffic is being blocked by the firewall. You can check the firewall logs to rule that out.  Have you added/removed any firewall rules.

    Make sure that Automatic Outbound NAT is enabled in Firewall: NAT: Outbound:

    Steve



  • @stephenw10:

    Ok so connectivity is good on pfsense WAN and LAN clients can connect the pfSense LAN side. In which case routing is not working or traffic is being blocked by the firewall. You can check the firewall logs to rule that out.  Have you added/removed any firewall rules.

    Make sure that Automatic Outbound NAT is enabled in Firewall: NAT: Outbound:

    Steve

    I checked that the Automatic Outbound NAT was enabled and it was. Also I did not change any of the rules from the preconfigured. The firewall log is filled with many blocks but I don't know how to interpret them.



  • Netgate Administrator

    Hmm, odd firewall hits. I assume the redacted destination IP is your WAN address? The odd thing is that it has 443 as the source port.  :-\ Anyway they are all hits on WAN which the firewall is correctly blocking by default. If the firewall was preventing your clients send traffic out you would see hits on LAN. Unless you have changed the rules these will be allowed by the default 'lan to any' rule.
    Ok so outbound NAT is set to auto (I'm not sure how to check that rules are actually being added here  :-). The other thing that commonly breaks routing is a subnet conflict or subnet mask misconfiguration but yours look OK to me.  :-
    That in no way explains why it works when you have wan set to dhcp either.

    Steve


  • Netgate Administrator

    I think at this point I would run a packet capture on the WAN interface to check that ping requests are being correctly routed or replied to. However I'm not sure how well that will work in a VM.

    Steve



  • Those IPs are ordinary places that people would use:
    69.171.224.32 Facebook
    23.48.50.110 Akamai Technologies - a web content provider that lots of pages reference
    The packets are from port 443 - https - anyone starting a Facebook session would send stuff to Facebook on port 443, and should get an initial response back from port 443 which may soon hand off the comms for their new session to another port.
    These packets from 443 should match a firewall state setup when the original user's packet went from LAN, NAT translation and out WAN. They should not be blocked, regardless of your firewall rules.
    It seems that something weird is happening with the firewall states.
    I am not familiar with all the options available when turning NAT off and on. In Firewall:NAT or System:Advanced:Firewall & NAT there might be setting that is not in its default state.
    Enough talk, I'll let someone else thin kof what to look at next.


  • Netgate Administrator

    Hmm, stateful firewall broken. Had not considered that!
    I have no idea how one might break that or how switching from a dhcp assigned WAN to static might do it.  :-\

    Steve



  • I went into NAT configuration and moved from auto to manual. It created some rules I deleted those and then moved back to auto from manual. It seems to have fixed the blocks being reported in the firewall. Still no connectivity.

    I did a packet capture on the wan interface… I then attempted to browse to google.com from a local device. Packets go through but I once again don't know how to interpret it.

    OK scratch that I am still getting blocked...



  • Could someone take a look at these logs from the packet capture (I picked an interface and then on a local device attempted to go to google.com):

    
    WAN Interface
    
    16:57:41.101959 IP 75.144.79.144.13192 > 74.125.225.78.443: tcp 0
    16:57:41.108078 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23150, length 44
    16:57:41.125294 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
    16:57:41.144520 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23150, length 44
    16:57:41.455705 IP 10.0.0.0 > 224.0.0.1: igmp
    16:57:41.580017 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
    16:57:41.664690 IP 75.144.79.144.3756 > 74.125.225.78.443: tcp 0
    16:57:41.685577 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
    16:57:42.039584 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
    16:57:42.118017 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23406, length 44
    16:57:42.149849 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23406, length 44
    16:57:42.180303 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
    16:57:42.638573 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
    16:57:43.128024 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23662, length 44
    16:57:43.161202 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23662, length 44
    16:57:43.380435 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
    16:57:43.838306 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
    16:57:43.995745 IP 75.144.79.144.39147 > 74.125.225.70.443: tcp 0
    16:57:44.017177 IP 74.125.225.70.443 > 75.144.79.144.39147: tcp 0
    16:57:44.098672 IP 75.144.79.144.13192 > 74.125.225.78.443: tcp 0
    16:57:44.120593 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
    16:57:44.137956 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 23918, length 44
    16:57:44.170392 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 23918, length 44
    16:57:44.383626 IP 74.125.225.70.443 > 75.144.79.144.39147: tcp 0
    16:57:44.664647 IP 75.144.79.144.3756 > 74.125.225.78.443: tcp 0
    16:57:44.685868 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
    16:57:44.699328 IP 75.144.79.144.36950 > 74.125.225.68.443: tcp 0
    16:57:44.722696 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
    16:57:44.728673 IP 75.144.79.144.4217 > 74.125.225.70.443: tcp 0
    16:57:44.749215 IP 74.125.225.70.443 > 75.144.79.144.4217: tcp 0
    16:57:44.966891 IP 75.144.79.144.32177 > 74.125.225.68.443: tcp 0
    16:57:44.988638 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
    16:57:45.147931 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24174, length 44
    16:57:45.180448 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24174, length 44
    16:57:45.182179 IP 74.125.225.70.443 > 75.144.79.144.4217: tcp 0
    16:57:45.184711 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
    16:57:45.410414 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
    16:57:45.781167 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
    16:57:45.783714 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
    16:57:46.010282 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
    16:57:46.157899 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24430, length 44
    16:57:46.190517 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24430, length 44
    16:57:46.237759 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
    16:57:46.691304 IP 75.144.79.144.38380 > 173.194.68.125.443: tcp 0
    16:57:46.734180 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
    16:57:46.941749 IP 75.144.79.144.33876 > 173.194.68.125.443: tcp 0
    16:57:46.982674 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
    16:57:46.983864 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
    16:57:47.128039 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
    16:57:47.167852 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24686, length 44
    16:57:47.202763 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24686, length 44
    16:57:47.210433 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
    16:57:47.282514 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
    16:57:47.700973 IP 75.144.79.144.36950 > 74.125.225.68.443: tcp 0
    16:57:47.723263 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
    16:57:47.729600 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
    16:57:47.882395 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
    16:57:47.961005 IP 75.144.79.144.32177 > 74.125.225.68.443: tcp 0
    16:57:47.982889 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
    16:57:48.116661 IP 75.144.79.144.26289 > 75.75.76.76.53: UDP, length 28
    16:57:48.116694 IP 75.144.79.144.26289 > 8.8.8.8.53: UDP, length 28
    16:57:48.116721 IP 75.144.79.144.26289 > 8.8.4.4.53: UDP, length 28
    16:57:48.116746 IP 75.144.79.144.26289 > 75.75.75.75.53: UDP, length 28
    16:57:48.132922 IP 75.75.76.76.53 > 75.144.79.144.26289: UDP, length 204
    16:57:48.136766 IP 75.144.79.144.17085 > 74.125.225.130.80: tcp 0
    16:57:48.153083 IP 8.8.4.4.53 > 75.144.79.144.26289: UDP, length 204
    16:57:48.153130 IP 8.8.8.8.53 > 75.144.79.144.26289: UDP, length 204
    16:57:48.164292 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
    16:57:48.167216 IP 75.75.75.75.53 > 75.144.79.144.26289: UDP, length 204
    16:57:48.177827 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 24942, length 44
    16:57:48.209769 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 24942, length 44
    16:57:48.456216 IP 10.0.0.0 > 224.0.0.1: igmp
    16:57:48.549640 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
    16:57:48.930197 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
    16:57:49.084248 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
    16:57:49.149509 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
    16:57:49.187781 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25198, length 44
    16:57:49.221121 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 25198, length 44
    16:57:49.385864 IP 74.125.225.68.443 > 75.144.79.144.36950: tcp 0
    16:57:49.611598 IP 74.125.225.68.443 > 75.144.79.144.32177: tcp 0
    16:57:49.695145 IP 75.144.79.144.38380 > 173.194.68.125.443: tcp 0
    16:57:49.741328 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
    16:57:49.945167 IP 75.144.79.144.33876 > 173.194.68.125.443: tcp 0
    16:57:49.987475 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
    16:57:50.108172 IP 75.144.79.144.13192 > 74.125.225.78.443: tcp 0
    16:57:50.135905 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
    16:57:50.197745 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25454, length 44
    16:57:50.229454 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 25454, length 44
    16:57:50.351753 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
    16:57:50.583027 IP 74.125.225.78.443 > 75.144.79.144.13192: tcp 0
    16:57:50.668264 IP 75.144.79.144.3756 > 74.125.225.78.443: tcp 0
    16:57:50.691144 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
    16:57:51.040863 IP 74.125.225.78.443 > 75.144.79.144.3756: tcp 0
    16:57:51.139318 IP 75.144.79.144.17085 > 74.125.225.130.80: tcp 0
    16:57:51.160980 IP 74.125.225.130.80 > 75.144.79.144.17085: tcp 0
    16:57:51.207707 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25710, length 44
    16:57:51.242954 IP 8.8.8.8 > 75.144.79.144: ICMP echo reply, id 46666, seq 25710, length 44
    16:57:51.332369 IP 173.194.68.125.443 > 75.144.79.144.38380: tcp 0
    16:57:51.484095 IP 173.194.68.125.443 > 75.144.79.144.33876: tcp 0
    16:57:52.217676 IP 75.144.79.144 > 8.8.8.8: ICMP echo request, id 46666, seq 25966, length 44
    
    ------------------------------------------------------------------
    LAN Interface
    
    16:58:53.524036 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
    16:58:53.664922 IP 192.168.0.200.64336 > 74.125.225.134.443: tcp 0
    16:58:53.723976 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
    16:58:53.724061 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
    16:58:53.724063 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
    16:58:53.724594 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
    16:58:53.724628 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
    16:58:53.724630 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
    16:58:53.724632 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
    16:58:53.724634 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
    16:58:53.725108 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
    16:58:53.725146 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
    16:58:53.725148 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
    16:58:53.725150 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 1460
    16:58:53.725152 IP 192.168.0.99.80 > 192.168.0.200.64343: tcp 495
    16:58:53.725640 IP 192.168.0.200.64343 > 192.168.0.99.80: tcp 0
    16:58:53.733891 IP 192.168.0.200.64337 > 74.125.142.125.443: tcp 0
    16:58:53.983895 IP 192.168.0.200.64338 > 74.125.142.125.443: tcp 0
    16:58:54.229110 IP 192.168.0.200.50855 > 192.168.0.99.53: UDP, length 33
    16:58:54.246739 IP 192.168.0.99.53 > 192.168.0.200.50855: UDP, length 49
    16:58:54.455911 IP 10.0.0.0 > 224.0.0.1: igmp
    16:58:54.907004 IP 192.168.0.200.64339 > 74.125.225.32.443: tcp 0
    16:58:55.137092 IP 192.168.0.200.64340 > 74.125.225.32.443: tcp 0
    16:58:56.767269 IP 192.168.0.200.64341 > 74.125.225.131.443: tcp 0
    16:58:56.987238 IP 192.168.0.200.64342 > 74.125.225.131.443: tcp 0
    16:58:57.843056 IP 192.168.0.200.64350 > 74.125.225.130.80: tcp 0
    16:58:58.612801 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
    16:58:59.014081 IP 192.168.0.200.64351 > 74.125.225.134.443: tcp 0
    16:58:59.363421 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
    16:58:59.773368 IP 192.168.0.200.64352 > 74.125.225.134.443: tcp 0
    16:59:00.113507 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
    16:59:00.843563 IP 192.168.0.200.64350 > 74.125.225.130.80: tcp 0
    16:59:00.910479 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
    16:59:01.455647 IP 10.0.0.0 > 224.0.0.1: igmp
    16:59:01.660603 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
    16:59:02.013532 IP 192.168.0.200.64351 > 74.125.225.134.443: tcp 0
    16:59:02.410700 IP 192.168.0.200.137 > 192.168.0.255.137: UDP, length 50
    16:59:02.773546 IP 192.168.0.200.64352 > 74.125.225.134.443: tcp 0
    16:59:03.163869 IP 192.168.0.200.52811 > 192.168.0.99.53: UDP, length 37
    16:59:03.182386 IP 192.168.0.99.53 > 192.168.0.200.52811: UDP, length 106
    16:59:03.187650 IP 192.168.0.200.64354 > 207.46.206.137.80: tcp 0
    

    I don't care about hiding the external IP anymore…. I'm not going to be using it for long.


Log in to reply