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.

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.

Forum Discussion

rwendt_291390

Nimbostratus

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.

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

VernonWells

Employee

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

Nimbostratus

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

Nimbostratus

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

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

Nimbostratus

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

Nimbostratus

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

Recent Discussions

Under Attack? F5 Will Help You.
Contacting F5 Support?

DevCentral Quicklinks

* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com

Discover DevCentral Connects

* Podcasts
* Social Channels
* Video Streaming

Forum Discussion

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

Recent Discussions

F5 DDOS Solution

iRule for public IP access to specific section of my URL

APM RDP custom parameters

Reporting Help Needed

Switch ssl profile based on weak cipher detection via IRULE

Related Content

Google bot Unreachable on 301 redirect iRules

TCP monitor with sending a byte sequence

iRULE regsub error

owa iapp assign irule

F5 BIG IQ VE suddenly unreachable

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS