I am running out of ideas why BIG-IP behaves as in cases described below, either it's my lack of knowledge, expected behavior or bug.
Tested on v11.2.0HF7 Active-Passive cluster.
If SNAT object is set to Enabled on with empty Selected stats are not increased.
Question is why SNAT object stats are increased if packets are processed by wildcard VS and src IP on external VLAN is translated to floating Self IP (10.129.10.13) not SNAT object IP (10.129.10.40)
Same setup as above
Why self IP on external VLAN replies to pings?
According to all articles and manuals I saw, there are port exceptions no matter what Port Lockdown is set for self IP. Those are Mirroring port (1028), Config Sync port (4353) and ICMP.
For HA related ports,t there is as well note that those are open for packets received from peer IP - at least that is my understanding.
Why 4353 is accepting connection and 1028 is not - both connections are performed from the same IP - one that is not peer IP.
That could be especially in case of Config Sync port. If anyone in the same network as self IP used for Config Sync can setup TCP connection, then he can as well send crafted packets that will break syncing process - at least it seems so.
So port exceptions in HA are accepting connections only from peer IP or from any IP in the same subnet as self IP?
Regarding SNAT issue, can anyone explain ehat this output means:
show ltm snat LAMP_subnet_to_ext detail
Bits In 30.5K
Bits Out 29.7K
Packets In 82
Packets Out 82
Current Connections 1
Maximum Connections 5
Total Connections 19
| Ltm::SNAT Pool: SNAT_to_Internet_pl
| Traffic ServerSide
| Bits In 0
| Bits Out 0
| Packets In 0
| Packets Out 0
| Current Connections 0
| Maximum Connections 0
| Total Connections 0
SNAT object is using SNAT Pool, SNAT pool is not seeing any traffic (so no src IP translations) but SNAT object sees traffic and even has open connections.
But when doing tmsh show sys connections there are only connections like that:
tmsh show sys connections
10.128.30.151:123 184.108.40.206:123 10.129.10.13:123 220.127.116.11:123 udp 169 (tmm: 0)
192.168.1.2:51914 192.168.1.1:1026 192.168.1.2:51914 192.168.1.1:1026 udp 0 (tmm: 0)
192.168.1.1:38978 192.168.1.2:1026 192.168.1.1:38978 192.168.1.2:1026 udp 0 (tmm: 0)
10.128.40.239:56372 10.128.40.110:8081 10.128.40.239:56372 10.128.40.110:8081 tcp 0 (tmm: 0)
So sure there are connections from subnet set in SNAT object (10.128.30.0/24) but those are handled by wildcard VS (server side src IP 10.129.10.13 - floating self ip - snat automap).
So what's going on here?
Stats stops to increase when I set Disable On in SNAT with internal VLAN selected. Is I have Enabled on with empty Selected then stats are still increasing.
Remember that there are multiple types of listeners, so the order of precedence is as follow:
IP : port
IP : * (all ports)
NW : port
NW : *
* : port
* : * (wildcard virtual server)
So first BIG-IP system check if there's an entry in the connection table.
By default PF don't affect existing connections, but they can be changed to filter existing connections.
Next we have the destination listeners or VSs, and then our source listeners (SNATs).
Within both destination and source listeners, they can be configured more or less specific.
Finally we process NATs.
I hope this helps.
I know all of that, problem is how this applies to situation I described?
We starting with no entries in session table
No traffic processed by destination listener - wildcard VS - so stats empty for VS
No traffic processed by source listener - SNAT object - so empty for SNAT
Now sending single ping from 10.128.30.152 to IP behind BIG-IP (so going via BIG-IP internal self IP - def gw for host)
Result is that both wildcard stats increase and SNAT object stats increase but SNAT translation is not using IP from SNAT object but external Self IP (wildcard VS has automap defined).
So what traffic processing is performed by SNAT object?
According to precedence you listed traffic is captured by destination listener object - wildcard VS - so should not ever be processed by SNAT - at in fact thats the case!
Sure if wildcard VS would have SNAT set to none that SNAT object would kick in and perform src IP translation - but this is not the case.
But still stats of SNAT suggest something opposite, what those client side stats for SNAT mean - that SNAT seen packets that it could potentially process but because of other higher precedence objects had to give up - that's why no stats on server side (SNAT Pool)?
That is quite misleading isn't it?