Forum Discussion
Bilal_9919
Nimbostratus
NimbostratusiRule to change Destination IP
Hello Team,
I am using clone pool to duplicate the syslog packets to syslog-ng. I see packets been duplicated on F5 and forwarded to host on clone pool by wiresharking on syslog-ng and also the utilisation counter on F5. This is the traffic flow:
1. Client send syslog messages to F5 VIP (1.1.1.1);
2. F5 receives the packet and sends to standard load balancing pool (2.2.2.2);
3. At same time, packet is duplicated and send to clone pool member syslog-ng (3.3.3.3);
4. The duplicated packet sent to syslog-ng doesn't change the packet destination IP and still preserves as 1.1.1.1 F5 VIP. When packet is received on 3.3.3.3 the destination MAC is of 3.3.3.3, but destination IP is 1.1.1.1. I can confirm this via wireshark and sees on physical interface, but IP layer checking discard the packet, because of mismatch of MAC and IP.
I confirm this by assiging the secondary IP on syslog-ng as 1.1.1.1 and I start receiving the packet...just a nasty trick. The clone pool is doing it's job by not changing the destination IP as it was designed for IDS.
I am thinking to write an iRule to change the destination IP to syslog-ng (3.3.3.3) from 1.1.1.1. when packet is duplicated and before sent on wire.
I am not a good programmer as someone please help in writing this iRule.
Thanks in advance.
nitassEmployee
not sure if this is acceptable instead of changing destination ip.[root@ve1023:Active] config b virtual bar list virtual bar { snat automap pool foo destination 172.28.19.79:514 ip protocol 17 rules myrule } [root@ve1023:Active] config b pool foo list pool foo { members 200.200.200.101:514 {} } [root@ve1023:Active] config b pool syslog_server_pool list pool syslog_server_pool { members 200.200.200.111:514 {} } [root@ve1023:Active] config b rule myrule list rule myrule { when CLIENT_ACCEPTED { set hsl [HSL::open -proto UDP -pool syslog_server_pool] } when CLIENT_DATA { HSL::send $hsl [UDP::payload] } } on 200.200.200.101 [root@centos101 ~] nc -l -u 514 <106>This is a test message generated by Kiwi SyslogGen on 200.200.200.111 [root@centos111 ~] nc -l -u 514 <106>This is a test message generated by Kiwi SyslogGen
Bilal_9919Thanks Nitass - It seems you are suggesting not to use the clone pool functionality and employ hsl iRule to replicate the syslog packets to another destination. To be honest, if that works, I don't mind as long as packets are sent to two pools. One standard pool that will be used for load balancing and another pool mentioned as syslog servers.
I will test this tomorrow and will update you if this iRule works and achieve the desired results.
Thanks once again for your reply as I was checking entire weekend if someone has answered this question:)-
BH
Zachary_101609I'm actually in need of pretty much an identical solution. (Need to rewrite the destination IP on clone pool for UDP syslog traffic or the equivalent). Bilal, were you able to get this to work as you wished?
I tried the above, and it seems to 'partially' (?) work... I don't seem get an oubound UDP for every incoming syslog message. Also [just as important], I need to retain the source IP of the original message -- the outbound HSL::send sources from the F5.
-Zachary- Bilal_9919Thank you guys- I was able to make it work by duplicating the syslog messages to two different sources. With clone pool, it was duplicating, but with same destination IP. I created an iRule and it does duplicate events to two different destination; however, it was sending all together 3 messages, meaning two same messages to destination 1 and one unique message to destination 2.
This is what I did and it seems to resolve the issue.
when CLIENT_ACCEPTED {
set hsl [HSL::open -proto UDP -pool Pool_ABC_Replicated]
set hsl1 [HSL::open -proto UDP -pool Pool_OriginalReceiver]
}
when CLIENT_DATA {
HSL::send $hsl [UDP::payload]
}
Somehow, it resolved the issue and send only 2 duplicated packets to destination1 and destination2. When it was sending three packets when I was doing HSL::send $hsl1 [UDP::payload]
Thanks everyone for their much needed support that guided me to right direction. - Bilal_9919Just realised that you are right Zachary, the source was from F5 self-IP. Inorder to investigate the syslog messages, we will require real source, not F5. Did you find any workaround.
If you open the message on syslog receiver, it does show F5 and also if you drill the message, it shows the real IP.
Thanks,
Bilal Hansrod - nitassis it source ip address in ip header or in syslog message. if it is in syslog message, may we parse original syslog message and modify it?
just my 2 cents. - Bilal_9919It was source in IP header even in syslog message; however, syslog message shows bot IP.
Thanks again for your much needed help- - nitassthese are tcpdump and stream content of 2nd syslog server (irule). hostname in message shows client hostname (ve1100). you know since it is in payload, it is not changed by address translation. 172.28.19.80 is f5 selfip. i am not aware of how to change source ip in the ip header.
so, would it be possible to configure your syslog server to use ip or hostname in syslog message instead of ip in ip header when correlation?
tcpdump:
192011-12-21 14:37:10.05834822.018464172.28.19.80192.168.206.42Syslog223LOCAL0.NOTICE: Dec 20 22:36:24 ve1100 notice tmsh[10730]: 01420002:5: AUDIT - pid=10730 user=root folder=/Common module=(tmos) status=[Command OK] cmd_data=list sys db ucs.loadtime one-line\n
stream content:
<133>Dec 20 22:36:24 ve1100 notice tmsh[10730]: 01420002:5: AUDIT - pid=10730 user=root folder=/Common module=(tmos) status=[Command OK] cmd_data=list sys db ucs.loadtime one-line 
Varun_01_133381Bilal, Zachary, Nitass,
I am having a similar situation. Can you please share with me the final solution that you got.
Thanks.
Varun
julien_betacornHi, we have a cluster in this situation too. do you have a fix for this ? we are in 11.2.. this changes pending is really disturbing. thanks Julien..