Spoofed IP network behaviour

In this case, we spoof the IP of our client to 192.168.1.101.

When we do this, and send only a SYN packet to the server, we see the SYN on the client…

[root@cmhlcarchapp02 ~]# python spoof.py 1
09:37:52.469226 IP 192.168.1.101.49999 > cmhlparchodb01.mydomain.com.ncube-lm: Flags [S], seq 454:472, win 53270, length 18
[root@cmhlcarchapp02 ~]#

…and the receipt of the SYN on the server, a SYN and an ACK back to the client, and a reset from the client.

[root@cmhlparchodb01 trace]# tcpdump -i ens192 host 192.168.1.101
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), capture size 65535 bytes
09:37:53.047017 IP 192.168.1.101.49999 > cmhlparchodb01.mydomain.com.ncube-lm: Flags [S], seq 454:472, win 53270, length 18
09:37:53.047057 IP cmhlparchodb01.mydomain.com.ncube-lm > 192.168.1.101.49999: Flags [S.], seq 1774105243, ack 455, win 29200, options [mss 1460], length 0
09:37:53.048101 IP 192.168.1.101.49999 > cmhlparchodb01.mydomain.com.ncube-lm: Flags [R.], seq 1, ack 1, win 29200, length 0

Wait a minute, the client doesn’t exist!! Where did the server get the reset from? In this case, it was our firewall…

CLMBOH0001-FWL011/pri/act# sh capt archcapt

2 packets captured

   1: 13:36:25.098673       172.26.210.52.1521 > 192.168.1.101.49999: S 399788921:399788921(0) ack 455 win 29200  
   2: 13:36:25.098780       192.168.1.101.49999 > 172.26.210.52.1521: R 455:455(0) ack 399788922 win 29200 
2 packets shown
CLMBOH0001-FWL011/pri/act# 

The firewall sent the RST packet to the server when it couldn’t find the client to which the SYN/ACK should be sent. It also forwarded the spoofed client IP to the server, as shown above for both the server packet capture and the firewall capture.