Forum Discussion

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

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. ...
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.

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