static route versus IP forwarding VS

0.0.0.0/0 VS (PerfL4-type) actually is the best solution to establish internet connectivity for the back-end servers via F5 in your case. Static routes only define the next hop to reach a destination, but they do not effectively cause a routing to take place. They are useful as supplementary exceptions to default route.

I'll post the config I use in 99% of cases.

1. It consists of a custom FastL4 profile to make F5 a non-intrusive middleman (behave like a router)
2. A pool which has either one or more default gateways to reach Internet,
3. And a very broad 0.0.0.0/0 Virtual Server which listens on internal (server-side) VLANs that should have Internet connectivity via F5. This VS will only get a connection if there's no closer match available.

conf:

ltm profile fastl4 pr_fastl4_stateless {
    app-service none
    defaults-from fastL4
    loose-close enabled
    loose-initialization enabled
    reset-on-timeout disabled
}

ltm pool pool_default_gw {
    members {
        172.16.0.1:any {
            address 172.16.0.1
            session monitor-enabled
        }
    }
    monitor gateway_icmp
}

ltm virtual vs_0.0.0.0_any {
    destination 0.0.0.0:any
    mask any
    pool pool_default_gw
    profiles {
        pr_fastl4_stateless { }
    }
    source 0.0.0.0/0
    translate-port disabled
    vlans {
        vlan_server_side_2010
    }
    vlans-enabled
    vs-index 4
}

0.0.0.0/0 VS (PerfL4-type) actually is the best solution to establish internet connectivity for the back-end servers via F5 in your case. Static routes only define the next hop to reach a destination, but they do not effectively cause a routing to take place. They are useful as supplementary exceptions to default route.

I'll post the config I use in 99% of cases.

1. It consists of a custom FastL4 profile to make F5 a non-intrusive middleman (behave like a router)
2. A pool which has either one or more default gateways to reach Internet,
3. And a very broad 0.0.0.0/0 Virtual Server which listens on internal (server-side) VLANs that should have Internet connectivity via F5. This VS will only get a connection if there's no closer match available.

conf:

ltm profile fastl4 pr_fastl4_stateless {
    app-service none
    defaults-from fastL4
    loose-close enabled
    loose-initialization enabled
    reset-on-timeout disabled
}

ltm pool pool_default_gw {
    members {
        172.16.0.1:any {
            address 172.16.0.1
            session monitor-enabled
        }
    }
    monitor gateway_icmp
}

ltm virtual vs_0.0.0.0_any {
    destination 0.0.0.0:any
    mask any
    pool pool_default_gw
    profiles {
        pr_fastl4_stateless { }
    }
    source 0.0.0.0/0
    translate-port disabled
    vlans {
        vlan_server_side_2010
    }
    vlans-enabled
    vs-index 4
}

Hi,

First of all check stats of your Forwarding (IP) server when doing ping - if traffic is intercepted by this VS you will see packets reported, if you can't see packets then some other object is catching your traffic.

Of course it would be better to do tcpdump on interface facing your Linux servers. Something like that:

tcpdump -nni [your interface or vlan name facing Linux servers]:nnn -s0 'host [ip of Linux from which ping is started] and icmp'

In trace you should see BIG-IP listener like that lis=/Common/your_listener_name

If you want your wildcard VS (either Performance L4 or Forwarding IP) to only catch SMTP traffic then you can set Service Port to 25 (or port actually used by your servers to connect).

Considering VS config posted by Hannes I would say most important omission is that along with translate-port disabled you should have translate-address disabled.

Second would be that SNAT is not enabled. You need at least SNAT Automap to have replies from destination servers reach BIG-IP - of course assuming that you will not have route to 10.21.1.0/24 network configured on devices between BIG-IP and Internet to point to BIG-IP interface in 144.144.144.0/24 network.

I would say that setting fastL4 profile to loose-close and loose-initialization is not necessary and a bit dangerous.

We are talking here about connections initiated by servers to Internet, so they always should start with proper 3 Way Handshake.

As all traffic will be flowing via VS (not like with Direct Server Return setup) so BIG-IP will see as well all TCP close attempts (FIN packets).

Enabling loose-initialization allows bad formed connections or malicious packets to reach Internet - just my opinion.

And if loose options are not used, then it's better to enable reset-on-timeout.

Sure if you don't care what is leaving your network you can keep suggested config.

Piotr

Thanks to all of you trying to help. I am reading carefully your posts and try to extract what i can understand and keeps on testing...Very very sorry to keep on being a bit lost and therefore bothering you...

-disabled all my virtual servers BUT the IP forwarding one (it is a test F5 device) to be sure some traffic cannot be catched by another VS

-reset the statistics on this IP forwarding VS

-tcpdump on the F5 in front of my linux servers

Case 1 : the IP forwarding VS is targetting 0.0.0.0/0

ltm virtual IP_Forwarding_any {
    destination 0.0.0.0:any
    ip-forward
    mask any
    profiles {
        fastL4 { }
    }
    source 10.21.1.67/32
    source-address-translation {
        type automap
    }
    translate-address disabled
    translate-port disabled
    vs-index 28
}

Ping does not work :

root@chgva-srv-smt02:~ ping www.google.fr
PING www.google.fr (216.58.198.35) 56(84) bytes of data.
From 10.21.1.18 icmp_seq=1 Destination Net Unreachable
From 10.21.1.18 icmp_seq=2 Destination Net Unreachable

N.B. : 10.21.1.18 is the floating self IP of my F5 device.

On tcpdump on my F5 (listening on all interfaces) i can see the ICMP requests to mil04s04 (which is probably google), but part of them only (seems to be 1 out of 2, why ????) going through the IP forwarding VS :

[admin@f503:Active] ~  tcpdump -i 0.0 -vv host 10.21.1.67|grep ICMP
tcpdump: listening on 0.0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:48:01.882920 IP (tos 0x0, ttl 64, id 53093, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f3.1e100.net: ICMP echo request, id 51313, seq 2234, length 64 in slot1/tmm0 lis=/Common/IP_Forwarding_any
11:48:01.882941 IP (tos 0x0, ttl 255, id 12459, offset 0, flags [DF], proto ICMP (1), length 56)
    10.21.1.18 > 10.21.1.67: ICMP net mil04s04-in-f3.1e100.net unreachable, length 36
        IP (tos 0x0, ttl 63, id 53093, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f3.1e100.net: ICMP echo request, id 51313, seq 2234, length 64 out slot1/tmm0 lis=
11:48:02.882863 IP (tos 0x0, ttl 64, id 53243, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f3.1e100.net: ICMP echo request, id 51313, seq 2235, length 64 in slot1/tmm0 lis=/Common/IP_Forwarding_any
11:48:02.882877 IP (tos 0x0, ttl 255, id 12465, offset 0, flags [DF], proto ICMP (1), length 56)
    10.21.1.18 > 10.21.1.67: ICMP net mil04s04-in-f3.1e100.net unreachable, length 36
        IP (tos 0x0, ttl 63, id 53243, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f3.1e100.net: ICMP echo request, id 51313, seq 2235, length 64 out slot1/tmm0 lis=
11:48:03.882808 IP (tos 0x0, ttl 64, id 53354, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f3.1e100.net: ICMP echo request, id 51313, seq 2236, length 64 in slot1/tmm0 lis=/Common/IP_Forwarding_any
11:48:03.882824 IP (tos 0x0, ttl 255, id 12471, offset 0, flags [DF], proto ICMP (1), length 56)

The VS statistics show that traffic IN but no OUT

Seems that the ICMP requests reach the F5 but then the F5 have no route to internet and herefore does not know what to do (hence the traffic out of VS = 0 ?)

In such case i would need a static route ? I created one as such :

Name    Internet
Partition / Path    Common
Description 
Destination 0.0.0.0
Netmask 0.0.0.0
Resource    Gateway Address   144.144.144.129

Now ping does not give any message anymore (at least i don't have the "Destination Net unreachable" anymore). tcpdump show that only the ICMP requests arrive (now displaying the /Common/IP_Forwarding_any VS name for each and every ICMP request, which was not the case before) :

[admin@f5g03:Active] ~  tcpdump -i 0.0 -vv host 10.21.1.67|grep ICMP
tcpdump: listening on 0.0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:03:09.801031 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 40)
    10.21.1.18 > 10.21.1.67: ICMP echo request, id 29803, seq 61240, length 20 out slot1/tmm0 lis=
12:03:09.801351 IP (tos 0x0, ttl 64, id 5304, offset 0, flags [none], proto ICMP (1), length 40)
    10.21.1.67 > 10.21.1.18: ICMP echo reply, id 29803, seq 61240, length 20 in slot1/tmm0 lis=
12:03:09.869465 IP (tos 0x0, ttl 64, id 35972, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f35.1e100.net: ICMP echo request, id 51313, seq 3142, length 64 in slot1/tmm0 lis=/Common/IP_Forwarding_any
12:03:10.869492 IP (tos 0x0, ttl 64, id 36196, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f35.1e100.net: ICMP echo request, id 51313, seq 3143, length 64 in slot1/tmm0 lis=/Common/IP_Forwarding_any
12:03:11.869374 IP (tos 0x0, ttl 64, id 36369, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f35.1e100.net: ICMP echo request, id 51313, seq 3144, length 64 in slot1/tmm0 lis=/Common/IP_Forwarding_any
12:03:12.869384 IP (tos 0x0, ttl 64, id 36374, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f35.1e100.net: ICMP echo request, id 51313, seq 3145, length 64 in slot1/tmm0 lis=/Common/IP_Forwarding_any
12:03:13.869423 IP (tos 0x0, ttl 64, id 36616, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f35.1e100.net: ICMP echo request, id 51313, seq 3146, length 64 in slot1/tmm0 lis=/Common/IP_Forwarding_any

Statistics of the VS again shows traffic IN but not OUT. Here i am sure it goes through my IP forwarding VS but i don't receive the answer means i need to further investigate on the FW/gateway side i guess. Now let's have a look at case 2 ....

Case 2 : the IP forwarding VS have the destination IP :

ltm virtual IP_Forwarding_any {
    destination 216.58.198.35:any
    ip-forward
    mask 255.255.255.255
    profiles {
        fastL4 { }
    }
    source 10.21.1.67/32
    source-address-translation {
        type automap
    }
    translate-address disabled
    translate-port disabled
    vs-index 28
}

Ping works fine :

root@chgva-srv-smt02:~ ping www.google.fr
PING www.google.fr (216.58.198.35) 56(84) bytes of data.
64 bytes from mil04s04-in-f35.1e100.net (216.58.198.35): icmp_seq=1 ttl=255 time=0.172 ms
64 bytes from mil04s04-in-f35.1e100.net (216.58.198.35): icmp_seq=2 ttl=255 time=0.356 ms

tcpdump looks fine :

[admin@f5g03:Active] ~  tcpdump -i DMZ-intern -vv host 10.21.1.67|grep ICMP
tcpdump: listening on DMZ-intern, link-type EN10MB (Ethernet), capture size 65535 bytes
11:10:58.907658 IP (tos 0x0, ttl 64, id 36299, offset 0, flags [DF], proto ICMP (1), length 84)
    10.21.1.67 > mil04s04-in-f3.1e100.net: ICMP echo request, id 51313, seq 11, length 64 in slot1/tmm0 lis=
11:10:58.907691 IP (tos 0x0, ttl 255, id 1298, offset 0, flags [DF], proto ICMP (1), length 84)
    mil04s04-in-f3.1e100.net > 10.21.1.67: ICMP echo reply, id 51313, seq 11, length 64 out slot1/tmm0 lis=

Very surprisingly to me :

1) the VS statistics remains stucked to 0 2) ping works fine (without any route)

Would means the traffic goes some other way without my IP forward VS but what is more than strange is that the ping starts working fine as soon as i set the proper google destination IP is this same IP forward VS ???????

More than thanks if one of you keeps on trying to help me