I am using iptables to change the ip address of a snmptrap packet so it looks like it came from different device. I wrote a PERL script that I pass flags to and it sends the simulated traps but I ran into a issue when trying to send a trap for one IP and then immediately trying to send another trap for a different IP. If I don't wait 30 seconds in between sending the first trap and the second trap, the second trap always has the IP from the first trap. This can be seen using 'tcpdump -i eth0 port 162' in another terminal.
I reproduced on the command line outside of the PERL script. Here are the three commands involved:
#I first add a rule for the IP that I want the trap to have:
iptables -t nat -A POSTROUTING -p UDP --dport 162 -j SNAT --to 10.7.3.1
#Then I send the trap (43.150 is the trap destination):
snmptrap -v1 -c public 192.168.43.150 1.3.6.1.4.1.17373 "" 6 1 "" 1.3.6.1.4.1.17373.3.2.1 i 5
#And then I flush the iptables nat table POSTROUTING chain:
iptables -t nat -F POSTROUTING
After the flush, the rule is immediately gone from iptables but like I said, if I don't wait 30 seconds before sending the second trap, the second trap will have the IP used for the first trap even though the iptable has a new rule for the second IP.
I saw a --ctexpire option for the connection tracking module of iptables but not entirely sure that expires a rule like I am hoping for. It certainly didn't seem to work when I experimented with the option.
I am guessing this might be some type of timeout on the UDP protocol stack but again, I am not entirely sure.
Any idea on how I could fire the two different traps back to back and have them work correctly without waiting 30+ seconds? Or even just why this is happening, any help is greatly appreciated. TIA