Forum Discussion

rwendt_291390's avatar
rwendt_291390
Icon for Nimbostratus rankNimbostratus
Sep 22, 2016
Solved

How do i send an ICMP Dest port unreachable on an irule?

I have a ip forwarding virtual server that is supposed to reject packets not in my defined datagroup server_pools destined for a subset of the virtual servers we have. This functionality is working.

Below is the iRule i am using for this

when CLIENT_ACCEPTED {

    Is client IP address defined in the server_pools?   
   if { [class match [IP::client_addr] equals server_pools] }{
      forward
      log local0. "Request accepted from client: [IP::client_addr] -> [IP::local_addr]"
   } else {
    reject
    log local0. "Request rejected from client: [IP::client_addr] -> [IP::local_addr]"
   }
}

However if you traceroute to the vip's they issue a ICMP time exceeded in-transit message. Instead of a ICMP destination port unreachable which lets the traceroute program know it has reached its last hop.

IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36

Is there anyway to manually send this message? I know to test for UDP vs TCP i can use the following and change the protocol number.

if {[IP::protocol] == 17 }{
}

Any help would be appreciated.

BIG-IP
iRules
security
  • Vernon_97235's avatar
    Vernon_97235
    Sep 24, 2016

    It appears (on 12.1.1, at least) that the behavior of the 

    reject
    command differs based on whether address translation is enabled. When it is, as I say, an ICMP Port Unreachable message is returned (for UDP traffic). When it is disabled, the behavior you see occurs.

    There is no way to send a specific, explicit ICMP response from an iRule. However, a "Reject" type server will send an ICMP Port Unreachable in any case. So, you could create a "Reject" virtual server that is bound to no VLAN:

    ltm virtual vs-reject {
    destination 0.0.0.0:any
    mask any
    profiles {
        fastL4 { }
    }
    reject
    source 0.0.0.0/0
    translate-address enabled
    translate-port enabled
    vlans-enabled
    vs-index 6
}

    Then, in your iRule, instead of using 

    reject
    , forward rejects to this VS:

    when CLIENT_ACCEPTED {
   if { ![class match [IP::client_addr] equals server_pools] }{
       virtual vs-reject
   }
}

    (Notice that the explicit 

    forward
    branch is unnecessary because the VS type is already Forwarding). For me, this produces an identical result for classic 
    traceroute
    (using UDP segments bound for random high-numbered ports), which you appear to be testing here.

12 Replies

Sort By
  • VernonWells's avatar
    VernonWells
    Icon for Employee rankEmployee
    Sep 22, 2016

    reject
    for UDP traffic should send an ICMP Port Unreachable message. Moreover, if the defined virtual server is not a wildcard port, then you should get a TTL Port Unreachable because 
    traceroute
    chooses a random high-numbered port, and there is no listener. If the defined virtual server is a wildcard port, this should still work because of the 
    reject
    . I just validated those two cases.

    Having said that, there are many things that could be happening here. Would you be willing to provide the Virtual Server definition? I'd also recommend performing a 

    tcpdump
    on the BIG-IP to see the message flow. Something like:

    tcpdump -nni 0.0 host  and '(udp or icmp)'

    where is the IP address of the client sourcing the 

    traceroute
    .

    • rwendt_291390's avatar
      rwendt_291390
      Icon for Nimbostratus rankNimbostratus
      Sep 22, 2016

      Here you go

          ltm virtual anycast-test {
    destination 10.0.1.0:any
    ip-forward
    mask 255.255.255.0
    profiles {
        fastL4 { }
    }
    rules {
        traceroute_dst_port_unreachable
    }
    source 0.0.0.0/0
    translate-address disabled
    translate-port disabled
    vs-index 88
}


[rwendt@bigip01a:Active:Standalone] ~  tcpdump -Snni 0.0 host 10.130.65.162
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
12:58:46.856504 IP 10.130.65.162.53759 > 10.0.1.10.33455: UDP, length 32
12:58:46.856542 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36
12:58:46.867761 IP 10.130.65.162.49707 > 10.0.1.10.33456: UDP, length 32
12:58:46.867810 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36
12:58:46.867943 IP 10.130.65.162.40103 > 10.0.1.10.33458: UDP, length 32
12:58:46.868055 IP 10.130.65.162.48104 > 10.0.1.10.33457: UDP, length 32
12:58:46.868074 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36

      In order to see the ICMP messages i cannot add the UDP filter as it does not require a transport protocol to work.

      Also traceroute relies on two ICMP messages: TTL Expired which tells it to send another probe but increment the TTL +1 and ICMP Destination port unreachable which tells it it has hit its destination.

      Because the F5' is sending this message the traceroute program keeps attempting to send more probes.

    • rwendt_291390's avatar
      rwendt_291390
      Icon for Nimbostratus rankNimbostratus
      Sep 22, 2016

      Sorry here is the output you were looking for

      [rwendt@bigip01a:Active:Standalone] ~  tcpdump -Snni 0.0 host 10.130.65.162 and '(udp or icmp)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
13:08:55.570652 IP 10.130.65.162.55329 > 10.0.1.10.33455: UDP, length 32
13:08:55.570719 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36
13:08:55.582433 IP 10.130.65.162.33398 > 10.0.1.10.33458: UDP, length 32
13:08:55.582308 IP 10.130.65.162.60831 > 10.0.1.10.33456: UDP, length 32
13:08:55.582351 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36
13:08:55.582427 IP 10.130.65.162.44240 > 10.0.1.10.33457: UDP, length 32
13:08:55.582446 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36
13:08:55.588069 IP 10.130.65.162.42427 > 10.0.1.10.33459: UDP, length 32
13:08:55.587890 IP 10.130.65.162.47450 > 10.0.1.10.33460: UDP, length 32
13:08:55.587946 IP 10.130.65.162.44289 > 10.0.1.10.33461: UDP, length 32
13:08:55.590292 IP 10.130.65.162.41853 > 10.0.1.10.33467: UDP, length 32
13:08:55.590349 IP 10.130.65.162.33884 > 10.0.1.10.33468: UDP, length 32
13:08:55.590054 IP 10.130.65.162.57048 > 10.0.1.10.33464: UDP, length 32
13:08:55.590160 IP 10.130.65.162.33487 > 10.0.1.10.33466: UDP, length 32
13:08:55.590173 IP 10.130.65.162.53773 > 10.0.1.10.33462: UDP, length 32
13:08:55.590004 IP 10.130.65.162.44827 > 10.0.1.10.33463: UDP, length 32
13:08:55.590128 IP 10.130.65.162.53012 > 10.0.1.10.33465: UDP, length 32
13:08:55.590799 IP 10.130.65.162.36698 > 10.0.1.10.33469: UDP, length 32
13:08:55.590889 IP 10.130.65.162.49268 > 10.0.1.10.33470: UDP, length 32
13:08:55.591090 IP 10.130.65.162.57680 > 10.0.1.10.33471: UDP, length 32
13:08:55.601142 IP 10.130.65.162.45059 > 10.0.1.10.33472: UDP, length 32
13:08:55.601247 IP 10.130.65.162.45469 > 10.0.1.10.33473: UDP, length 32
13:09:00.607541 IP 10.130.65.162.40011 > 10.0.1.10.33480: UDP, length 32
13:09:00.607478 IP 10.130.65.162.46072 > 10.0.1.10.33474: UDP, length 32
13:09:00.607410 IP 10.130.65.162.36413 > 10.0.1.10.33476: UDP, length 32
13:09:00.607459 IP 10.130.65.162.33898 > 10.0.1.10.33475: UDP, length 32
13:09:00.607655 IP 10.130.65.162.39592 > 10.0.1.10.33483: UDP, length 32
13:09:00.607668 IP 10.130.65.162.47929 > 10.0.1.10.33485: UDP, length 32
13:09:00.607676 IP 10.130.65.162.45340 > 10.0.1.10.33478: UDP, length 32
13:09:00.607794 IP 10.130.65.162.44528 > 10.0.1.10.33487: UDP, length 32
13:09:00.607807 IP 10.130.65.162.57087 > 10.0.1.10.33489: UDP, length 32
13:09:00.607610 IP 10.130.65.162.50706 > 10.0.1.10.33484: UDP, length 32
13:09:00.607753 IP 10.130.65.162.37789 > 10.0.1.10.33488: UDP, length 32
13:09:00.607569 IP 10.130.65.162.45223 > 10.0.1.10.33479: UDP, length 32
13:09:00.607580 IP 10.130.65.162.48047 > 10.0.1.10.33477: UDP, length 32
13:09:00.607584 IP 10.130.65.162.56565 > 10.0.1.10.33481: UDP, length 32
13:09:00.607588 IP 10.130.65.162.60607 > 10.0.1.10.33482: UDP, length 32
13:09:00.607756 IP 10.130.65.162.39660 > 10.0.1.10.33486: UDP, length 32
13:09:05.615805 IP 10.130.65.162.52331 > 10.0.1.10.33494: UDP, length 32
13:09:05.615923 IP 10.130.65.162.47112 > 10.0.1.10.33493: UDP, length 32
13:09:05.615943 IP 10.130.65.162.33172 > 10.0.1.10.33496: UDP, length 32
13:09:05.616119 IP 10.130.65.162.50400 > 10.0.1.10.33502: UDP, length 32
13:09:05.616201 IP 10.130.65.162.51447 > 10.0.1.10.33503: UDP, length 32
13:09:05.615932 IP 10.130.65.162.50248 > 10.0.1.10.33495: UDP, length 32
13:09:05.616049 IP 10.130.65.162.41185 > 10.0.1.10.33497: UDP, length 32
13:09:05.616064 IP 10.130.65.162.58917 > 10.0.1.10.33500: UDP, length 32
13:09:05.615738 IP 10.130.65.162.50925 > 10.0.1.10.33490: UDP, length 32
13:09:05.615782 IP 10.130.65.162.33378 > 10.0.1.10.33492: UDP, length 32
13:09:05.615924 IP 10.130.65.162.38505 > 10.0.1.10.33491: UDP, length 32
13:09:05.616141 IP 10.130.65.162.36198 > 10.0.1.10.33499: UDP, length 32
13:09:05.616152 IP 10.130.65.162.51870 > 10.0.1.10.33501: UDP, length 32
13:09:05.616242 IP 10.130.65.162.53833 > 10.0.1.10.33504: UDP, length 32
13:09:05.616455 IP 10.130.65.162.56722 > 10.0.1.10.33505: UDP, length 32
    • rwendt_291390's avatar
      rwendt_291390
      Icon for Nimbostratus rankNimbostratus
      Sep 26, 2016

      Ok so this was actually a lot easier a solution that i had thought previously. I created a reject vs only enabled on the frontend vlan and it works great. No iRule, no data group needed. 😄

      ltm virtual anycast-protect {
    destination 10.0.1.0:any
    mask 255.255.255.0
    profiles {
        fastL4 { }
    }
    reject
    source 0.0.0.0/0
    vlans {
        VIP_Net
    }
    vlans-enabled
    vs-index 98
  • Vernon_97235's avatar
    Vernon_97235
    Historic F5 Account
    Sep 22, 2016

    reject
    for UDP traffic should send an ICMP Port Unreachable message. Moreover, if the defined virtual server is not a wildcard port, then you should get a TTL Port Unreachable because 
    traceroute
    chooses a random high-numbered port, and there is no listener. If the defined virtual server is a wildcard port, this should still work because of the 
    reject
    . I just validated those two cases.

    Having said that, there are many things that could be happening here. Would you be willing to provide the Virtual Server definition? I'd also recommend performing a 

    tcpdump
    on the BIG-IP to see the message flow. Something like:

    tcpdump -nni 0.0 host  and '(udp or icmp)'

    where is the IP address of the client sourcing the 

    traceroute
    .

    • rwendt_291390's avatar
      rwendt_291390
      Icon for Nimbostratus rankNimbostratus
      Sep 22, 2016

      Here you go

          ltm virtual anycast-test {
    destination 10.0.1.0:any
    ip-forward
    mask 255.255.255.0
    profiles {
        fastL4 { }
    }
    rules {
        traceroute_dst_port_unreachable
    }
    source 0.0.0.0/0
    translate-address disabled
    translate-port disabled
    vs-index 88
}


[rwendt@bigip01a:Active:Standalone] ~  tcpdump -Snni 0.0 host 10.130.65.162
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
12:58:46.856504 IP 10.130.65.162.53759 > 10.0.1.10.33455: UDP, length 32
12:58:46.856542 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36
12:58:46.867761 IP 10.130.65.162.49707 > 10.0.1.10.33456: UDP, length 32
12:58:46.867810 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36
12:58:46.867943 IP 10.130.65.162.40103 > 10.0.1.10.33458: UDP, length 32
12:58:46.868055 IP 10.130.65.162.48104 > 10.0.1.10.33457: UDP, length 32
12:58:46.868074 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36

      In order to see the ICMP messages i cannot add the UDP filter as it does not require a transport protocol to work.

      Also traceroute relies on two ICMP messages: TTL Expired which tells it to send another probe but increment the TTL +1 and ICMP Destination port unreachable which tells it it has hit its destination.

      Because the F5' is sending this message the traceroute program keeps attempting to send more probes.

    • rwendt_291390's avatar
      rwendt_291390
      Icon for Nimbostratus rankNimbostratus
      Sep 22, 2016

      Sorry here is the output you were looking for

      [rwendt@bigip01a:Active:Standalone] ~  tcpdump -Snni 0.0 host 10.130.65.162 and '(udp or icmp)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
13:08:55.570652 IP 10.130.65.162.55329 > 10.0.1.10.33455: UDP, length 32
13:08:55.570719 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36
13:08:55.582433 IP 10.130.65.162.33398 > 10.0.1.10.33458: UDP, length 32
13:08:55.582308 IP 10.130.65.162.60831 > 10.0.1.10.33456: UDP, length 32
13:08:55.582351 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36
13:08:55.582427 IP 10.130.65.162.44240 > 10.0.1.10.33457: UDP, length 32
13:08:55.582446 IP 10.0.1.10 > 10.130.65.162: ICMP time exceeded in-transit, length 36
13:08:55.588069 IP 10.130.65.162.42427 > 10.0.1.10.33459: UDP, length 32
13:08:55.587890 IP 10.130.65.162.47450 > 10.0.1.10.33460: UDP, length 32
13:08:55.587946 IP 10.130.65.162.44289 > 10.0.1.10.33461: UDP, length 32
13:08:55.590292 IP 10.130.65.162.41853 > 10.0.1.10.33467: UDP, length 32
13:08:55.590349 IP 10.130.65.162.33884 > 10.0.1.10.33468: UDP, length 32
13:08:55.590054 IP 10.130.65.162.57048 > 10.0.1.10.33464: UDP, length 32
13:08:55.590160 IP 10.130.65.162.33487 > 10.0.1.10.33466: UDP, length 32
13:08:55.590173 IP 10.130.65.162.53773 > 10.0.1.10.33462: UDP, length 32
13:08:55.590004 IP 10.130.65.162.44827 > 10.0.1.10.33463: UDP, length 32
13:08:55.590128 IP 10.130.65.162.53012 > 10.0.1.10.33465: UDP, length 32
13:08:55.590799 IP 10.130.65.162.36698 > 10.0.1.10.33469: UDP, length 32
13:08:55.590889 IP 10.130.65.162.49268 > 10.0.1.10.33470: UDP, length 32
13:08:55.591090 IP 10.130.65.162.57680 > 10.0.1.10.33471: UDP, length 32
13:08:55.601142 IP 10.130.65.162.45059 > 10.0.1.10.33472: UDP, length 32
13:08:55.601247 IP 10.130.65.162.45469 > 10.0.1.10.33473: UDP, length 32
13:09:00.607541 IP 10.130.65.162.40011 > 10.0.1.10.33480: UDP, length 32
13:09:00.607478 IP 10.130.65.162.46072 > 10.0.1.10.33474: UDP, length 32
13:09:00.607410 IP 10.130.65.162.36413 > 10.0.1.10.33476: UDP, length 32
13:09:00.607459 IP 10.130.65.162.33898 > 10.0.1.10.33475: UDP, length 32
13:09:00.607655 IP 10.130.65.162.39592 > 10.0.1.10.33483: UDP, length 32
13:09:00.607668 IP 10.130.65.162.47929 > 10.0.1.10.33485: UDP, length 32
13:09:00.607676 IP 10.130.65.162.45340 > 10.0.1.10.33478: UDP, length 32
13:09:00.607794 IP 10.130.65.162.44528 > 10.0.1.10.33487: UDP, length 32
13:09:00.607807 IP 10.130.65.162.57087 > 10.0.1.10.33489: UDP, length 32
13:09:00.607610 IP 10.130.65.162.50706 > 10.0.1.10.33484: UDP, length 32
13:09:00.607753 IP 10.130.65.162.37789 > 10.0.1.10.33488: UDP, length 32
13:09:00.607569 IP 10.130.65.162.45223 > 10.0.1.10.33479: UDP, length 32
13:09:00.607580 IP 10.130.65.162.48047 > 10.0.1.10.33477: UDP, length 32
13:09:00.607584 IP 10.130.65.162.56565 > 10.0.1.10.33481: UDP, length 32
13:09:00.607588 IP 10.130.65.162.60607 > 10.0.1.10.33482: UDP, length 32
13:09:00.607756 IP 10.130.65.162.39660 > 10.0.1.10.33486: UDP, length 32
13:09:05.615805 IP 10.130.65.162.52331 > 10.0.1.10.33494: UDP, length 32
13:09:05.615923 IP 10.130.65.162.47112 > 10.0.1.10.33493: UDP, length 32
13:09:05.615943 IP 10.130.65.162.33172 > 10.0.1.10.33496: UDP, length 32
13:09:05.616119 IP 10.130.65.162.50400 > 10.0.1.10.33502: UDP, length 32
13:09:05.616201 IP 10.130.65.162.51447 > 10.0.1.10.33503: UDP, length 32
13:09:05.615932 IP 10.130.65.162.50248 > 10.0.1.10.33495: UDP, length 32
13:09:05.616049 IP 10.130.65.162.41185 > 10.0.1.10.33497: UDP, length 32
13:09:05.616064 IP 10.130.65.162.58917 > 10.0.1.10.33500: UDP, length 32
13:09:05.615738 IP 10.130.65.162.50925 > 10.0.1.10.33490: UDP, length 32
13:09:05.615782 IP 10.130.65.162.33378 > 10.0.1.10.33492: UDP, length 32
13:09:05.615924 IP 10.130.65.162.38505 > 10.0.1.10.33491: UDP, length 32
13:09:05.616141 IP 10.130.65.162.36198 > 10.0.1.10.33499: UDP, length 32
13:09:05.616152 IP 10.130.65.162.51870 > 10.0.1.10.33501: UDP, length 32
13:09:05.616242 IP 10.130.65.162.53833 > 10.0.1.10.33504: UDP, length 32
13:09:05.616455 IP 10.130.65.162.56722 > 10.0.1.10.33505: UDP, length 32
    • rwendt_291390's avatar
      rwendt_291390
      Icon for Nimbostratus rankNimbostratus
      Sep 26, 2016

      Ok so this was actually a lot easier a solution that i had thought previously. I created a reject vs only enabled on the frontend vlan and it works great. No iRule, no data group needed. 😄

      ltm virtual anycast-protect {
    destination 10.0.1.0:any
    mask 255.255.255.0
    profiles {
        fastL4 { }
    }
    reject
    source 0.0.0.0/0
    vlans {
        VIP_Net
    }
    vlans-enabled
    vs-index 98
  • VernonWells's avatar
    VernonWells
    Icon for Employee rankEmployee
    Sep 24, 2016

    It appears (on 12.1.1, at least) that the behavior of the 

    reject
    command differs based on whether address translation is enabled. When it is, as I say, an ICMP Port Unreachable message is returned (for UDP traffic). When it is disabled, the behavior you see occurs.

    There is no way to send a specific, explicit ICMP response from an iRule. However, a "Reject" type server will send an ICMP Port Unreachable in any case. So, you could create a "Reject" virtual server that is bound to no VLAN:

    ltm virtual vs-reject {
    destination 0.0.0.0:any
    mask any
    profiles {
        fastL4 { }
    }
    reject
    source 0.0.0.0/0
    translate-address enabled
    translate-port enabled
    vlans-enabled
    vs-index 6
}

    Then, in your iRule, instead of using 

    reject
    , forward rejects to this VS:

    when CLIENT_ACCEPTED {
   if { ![class match [IP::client_addr] equals server_pools] }{
       virtual vs-reject
   }
}

    (Notice that the explicit 

    forward
    branch is unnecessary because the VS type is already Forwarding). For me, this produces an identical result for classic 
    traceroute
    (using UDP segments bound for random high-numbered ports), which you appear to be testing here.

    • rwendt_291390's avatar
      rwendt_291390
      Icon for Nimbostratus rankNimbostratus
      Sep 26, 2016

      I'm running BIG-IP v11.4.0 (Build 2384.0) on this particular F5. We have about 18 F5 Bigip LTM's in service and the goal is to eventually upgrade them to 12.1.1.

      On this build it wont let me enable the port/address translation on the vip. In the GUI there is no option for this so I tried in the CLI and they never get enabled.

      [rwendt@bigip01a:Active:Standalone] ~  tmsh list ltm virtual anycast-protect
ltm virtual anycast-protect {
    destination 10.0.1.0:any
    ip-forward
    mask 255.255.255.0
    profiles {
        fastL4 { }
    }
    rules {
        anycast_protect
    }
    source 0.0.0.0/0
    translate-address disabled
    translate-port disabled
    vs-index 96
}
[rwendt@bigip01a:Active:Standalone] ~  tmsh modify ltm virtual anycast-protect translate-address enabled translate-port enabled
[rwendt@bigip01a:Active:Standalone] ~  tmsh list ltm virtual anycast-protect
ltm virtual anycast-protect {
    destination 10.0.1.0:any
    ip-forward
    mask 255.255.255.0
    profiles {
        fastL4 { }
    }
    rules {
        anycast_protect
    }
    source 0.0.0.0/0
    translate-address disabled
    translate-port disabled
    vs-index 96
}

      I tried making that reject server that isn't bound on any vlans. Then i used this ip forwarding vs to send it to the reject vs and it sends the ICMP port unreachable. However there is some weird behavior. Its sends alot of those messages now. Maybe because I cannot enable the port/address translation on it? I could send you a tcpdump of this however it was about 3000 packets for a single traceroute.

      In any event thanks for the input on all of this. I think upgrading might be in order here.

  • Vernon_97235's avatar
    Vernon_97235
    Historic F5 Account
    Sep 24, 2016

    It appears (on 12.1.1, at least) that the behavior of the 

    reject
    command differs based on whether address translation is enabled. When it is, as I say, an ICMP Port Unreachable message is returned (for UDP traffic). When it is disabled, the behavior you see occurs.

    There is no way to send a specific, explicit ICMP response from an iRule. However, a "Reject" type server will send an ICMP Port Unreachable in any case. So, you could create a "Reject" virtual server that is bound to no VLAN:

    ltm virtual vs-reject {
    destination 0.0.0.0:any
    mask any
    profiles {
        fastL4 { }
    }
    reject
    source 0.0.0.0/0
    translate-address enabled
    translate-port enabled
    vlans-enabled
    vs-index 6
}

    Then, in your iRule, instead of using 

    reject
    , forward rejects to this VS:

    when CLIENT_ACCEPTED {
   if { ![class match [IP::client_addr] equals server_pools] }{
       virtual vs-reject
   }
}

    (Notice that the explicit 

    forward
    branch is unnecessary because the VS type is already Forwarding). For me, this produces an identical result for classic 
    traceroute
    (using UDP segments bound for random high-numbered ports), which you appear to be testing here.

    • rwendt_291390's avatar
      rwendt_291390
      Icon for Nimbostratus rankNimbostratus
      Sep 26, 2016

      I'm running BIG-IP v11.4.0 (Build 2384.0) on this particular F5. We have about 18 F5 Bigip LTM's in service and the goal is to eventually upgrade them to 12.1.1.

      On this build it wont let me enable the port/address translation on the vip. In the GUI there is no option for this so I tried in the CLI and they never get enabled.

      [rwendt@bigip01a:Active:Standalone] ~  tmsh list ltm virtual anycast-protect
ltm virtual anycast-protect {
    destination 10.0.1.0:any
    ip-forward
    mask 255.255.255.0
    profiles {
        fastL4 { }
    }
    rules {
        anycast_protect
    }
    source 0.0.0.0/0
    translate-address disabled
    translate-port disabled
    vs-index 96
}
[rwendt@bigip01a:Active:Standalone] ~  tmsh modify ltm virtual anycast-protect translate-address enabled translate-port enabled
[rwendt@bigip01a:Active:Standalone] ~  tmsh list ltm virtual anycast-protect
ltm virtual anycast-protect {
    destination 10.0.1.0:any
    ip-forward
    mask 255.255.255.0
    profiles {
        fastL4 { }
    }
    rules {
        anycast_protect
    }
    source 0.0.0.0/0
    translate-address disabled
    translate-port disabled
    vs-index 96
}

      I tried making that reject server that isn't bound on any vlans. Then i used this ip forwarding vs to send it to the reject vs and it sends the ICMP port unreachable. However there is some weird behavior. Its sends alot of those messages now. Maybe because I cannot enable the port/address translation on it? I could send you a tcpdump of this however it was about 3000 packets for a single traceroute.

      In any event thanks for the input on all of this. I think upgrading might be in order here.