Forum Discussion

Jessica_42876's avatar
Jessica_42876
Icon for Nimbostratus rankNimbostratus
Jul 01, 2015

Destination net unreachable

Hi!

 

I have a problem.In the infraestructure the gateway of the Private Network is the selfIP into F5 device (10.5.3.1). In the server when I typed www.f5.com the answer of the ping is "Reply from 10.5.3.1: Destination net unreachable", but If I typed www.f5.com into the browser, I can navegate in the site. Do you know why is it happening?

 

Jessy.

 

application delivery
deployment
design
LTM
  • arpydays's avatar
    arpydays
    Icon for Nimbostratus rankNimbostratus
    Jul 01, 2015

    sounds like the browser may have proxy settings, what setup have you got on the F5 to forward traffic?

     

  • Ed_Summers's avatar
    Ed_Summers
    Icon for Nimbostratus rankNimbostratus
    Jul 01, 2015

    If that is the virtual (IP forwarding) being used for the outbound traffic, it is configured only for TCP (see first line under 'Configuration:'. That is why you can reach a web site (TCP connection) but not ping it (ICMP).

     

    If it is desired behavior, one method would be to change the IP protocol for this forwarding VS to "all". That will enable ICMP through the VS.

     

  • Jessica_42876's avatar
    Jessica_42876
    Icon for Nimbostratus rankNimbostratus
    Jul 01, 2015

    Hi!

     

    I change it to all protocols.

     

     

    and It doesn't work. what else could I do? Jessy

     

    • VernonWells's avatar
      VernonWells
      Icon for Employee rankEmployee
      Jul 02, 2015
      As @arpydays mentioned, do you have an HTTP proxy configured for your browser? That would explain why HTTP requests from a browser are working, but other traffic (like ping) is not. Have you added a default route to the BIG-IP (under Network >> Routes)? Are you using SNAT? The easiest thing to try is Automap SNAT. It is further down in the VS configuration, under "Source Address Translation". SNAT may or may not be required depending on your architecture. Also, ensure that "Address Translation" and "Port Translation" are not selected (ordinarily, setting the Type to "Forwarding (IP)" should unset those, but it's good to check).
  • Jessica_42876's avatar
    Jessica_42876
    Icon for Nimbostratus rankNimbostratus
    Jul 02, 2015

    Hi!

     

    I know that there is not a http proxy configured un the browser, I configured the default route 0.0.0.0 0.0.0.0 (IP of the router), I didn't use SNAT, but I try Enable the option (automap). Where could I check the "Address Translation" and "Port Translation" are not selected?

     

    Jessy

     

    • VernonWells's avatar
      VernonWells
      Icon for Employee rankEmployee
      Jul 02, 2015
      In newer versions, if "Forwarding (IP)" is selected, those options are suppressed from the Web UI. In tmsh: tmsh list ltm virtual will show the status of these. In order to troubleshoot, I recommend using tcpdump, as in: tcpdump -nnei 0.0 icmp and host where is the IP address you are attempting to ping. You should see each ICMP Echo Request twice: once inbound toward the BIG-IP, then once outbound from the BIG-IP. The tcpdump output should also indicate the ingress VLAN and the egress VLAN. If you are using SNAT, then the source address on ingress will differ from the source address on egress. Without SNAT, they will be the same on each side. You should naturally see the opposite as well, namely, the ICMP Echo Response twice (with the VLAN order reversed from the Request). Here are some possibilities: 1. You see the echo request enter but not leave: something is misconfigured on the BIG-IP or you are encountering a bug; 2. You see the request enter and leave, but no response: the destination doesn't respond to ping, a route failure is occurring, the traffic is not NATed as it leaves your enterprise border, or a firewall is blocking somewhere; 3. You see the request enter and leave, a response arrives, but no response leaves: something is misconfigured on the BIG-IP or you are encountering a bug; 4. You see the request enter and leave, then the response enter and leave: everything is likely properly configured. Verify that the destination MAC on the egressing ICMP Response is as expected. If so, then something between the BIG-IP and the client is blocking the response, or the client is misconfigured.
  • Jessica_42876's avatar
    Jessica_42876
    Icon for Nimbostratus rankNimbostratus
    Jul 03, 2015

    Hi!

     

    I have a bad news, I ejecute the command and it doesn't display nothing, What could I do?

     

    Jessy

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 06, 2015

    For IP forwarding through the BIG-IP, not necessarily forward (web) proxy, you need:

     

    1. that the client's default route be the self-IP of the BIG-IP

       

    2. that the BIG-IP's default route be the outbound router IP

       

    3. that you have an IP forwarding VIP listening on all IPs/ports/protocols, that it has port and address translation disabled, and optionally SNAT enabled

       

    4. that the client has a way to locally resolve DNS

       

    So when a client (browser) attempts to connect to it first does a DNS resolution and gets back 104.219.105.148. Because the BIG-IP is its default outbound route, the client passes the request to the BIG-IP. The BIG-IP, because it has an IP forwarding wildcard VIP, receives this request and forwards it to its default route (and optionally applies source address translation).

     

    If you can see the client's traffic arriving at the client side of the BIG-IP, then you know the client is properly configured. If you see the client's traffic leaving the BIG-IP to the outbound router, then you're reasonably sure the BIG-IP VIP is properly configured. As Ed states, ICMP may be getting held up because your VIP wasn't listening on UDP. Otherwise ICMP isn't an indicator of a good or bad configuration. You need to look at the actual client and server traffic through the proxy.