I am having a problem with a Linux guest that I upgraded in place from SLES 11 SP4 to SLES 12 SP3. The problem is that I cannot PuTTY into the server from my network (using a NAT address) nor from my clients' network using the real address. The PuTTY sessions time out. I believe that the request is getting to the SLES 12 system and is being rejected. SUSE Support (I have opened to SR's for this) says that the OS is working fine as I can SSH into this server from a server running on the same z/VM system on the same 10.17.1.156/26 network.

In order to minimize the application outage time for the PROD server, I decided to upgrade a clone of PROD's boot volume using a new, temporary, server. The upgrade was performed by creating a new virtual server, TEST, and restoring the PROD boot volume from tape (from a clean backup taken while PROD was shut down) to a new UCB address. I used the SLES12 REXX exec and specified a profile called TEST where the only difference from PROD is the IP address. The upgrade went smoothly and took about two hours to complete, with most of the time needed to modify about 25 config files where the upgrade created .rpmnew files.

When the starter linux system completed and rebooted the server, I was unable to PuTTY into the server using the new IP address. After lots of trial and error I opened an SR with support. They said that since ssh worked from another server, that there was nothing wrong with the SLES 12 system itself, that my network is the problem. After more testing I still thought the problem was with SLES 12 and opened a new SR and referred to the previous one. Support still says that SLES 12 isn't the problem.

As a test, I shut down a SLES 12 server that I am able PuTTY into (this server was upgraded to SLES 12 in mid-September and is at a different package level than TEST). I then modified /etc/sysconfig/netowrk/ifgcfg-eth0 on TEST and made it look exactly like the file on the server I just shut down. I shut down TEST and IPL'ed the guest (as opposed to rebooting the server). I verified from the console that TEST was using the IP address from the SLES 12 server that I was able to access via PuTTY. I cannot access TEST with PuTTY (using the real IP address from the clients' network, nor from my network using the NAT address).

I ran a tracert command from a Windows jump server on the client network. After the first hop was displayed by tracert I started seeing the following messages on the console for TEST:
Code:
2017-12-04T13:18:49.874194-06:00 wcs-mf-winxs-db2p kernel: IPv4: martian source 10.17.1.156 from 172.24.8.30, on dev eth0           
2017-12-04T13:18:49.874220-06:00 wcs-mf-winxs-db2p kernel: ll header: 00000000: 02 00 00 00 02 d6 00 26 51 cc f9 41 08 00        ...
....&Q..A..                                                                                                                         
2017-12-04T13:18:53.795374-06:00 wcs-mf-winxs-db2p kernel: IPv4: martian source 10.17.1.156 from 172.24.8.30, on dev eth0           
2017-12-04T13:18:53.795398-06:00 wcs-mf-winxs-db2p kernel: ll header: 00000000: 02 00 00 00 02 d6 00 26 51 cc f9 41 08 00        ...
....&Q..A..                                                                                                                         
2017-12-04T13:18:57.804186-06:00 wcs-mf-winxs-db2p kernel: IPv4: martian source 10.17.1.156 from 172.24.8.30, on dev eth0           
2017-12-04T13:18:57.804212-06:00 wcs-mf-winxs-db2p kernel: ll header: 00000000: 02 00 00 00 02 d6 00 26 51 cc f9 41 08 00        ...
....&Q..A..                                                                                                                         
2017-12-04T13:19:01.794178-06:00 wcs-mf-winxs-db2p kernel: IPv4: martian source 10.17.1.156 from 172.24.8.30, on dev eth0           
2017-12-04T13:19:01.794194-06:00 wcs-mf-winxs-db2p kernel: ll header: 00000000: 02 00 00 00 02 d6 00 26 51 cc f9 41 08 00        ...
....&Q..A..                                                                                                                         
2017-12-04T13:19:05.794200-06:00 wcs-mf-winxs-db2p kernel: IPv4: martian source 10.17.1.156 from 172.24.8.30, on dev eth0           
2017-12-04T13:19:05.794226-06:00 wcs-mf-winxs-db2p kernel: ll header: 00000000: 02 00 00 00 02 d6 00 26 51 cc f9 41 08 00        ...
....&Q..A..                                                                                                                         
2017-12-04T13:19:09.804197-06:00 wcs-mf-winxs-db2p kernel: IPv4: martian source 10.17.1.156 from 172.24.8.30, on dev eth0           
2017-12-04T13:19:09.804220-06:00 wcs-mf-winxs-db2p kernel: ll header: 00000000: 02 00 00 00 02 d6 00 26 51 cc f9 41 08 00        ...
....&Q..A..                                                                                                                         
2017-12-04T13:19:14.114174-06:00 wcs-mf-winxs-db2p kernel: IPv4: martian source 10.17.1.156 from 172.24.8.30, on dev eth0           
2017-12-04T13:19:14.114201-06:00 wcs-mf-winxs-db2p kernel: ll header: 00000000: 02 00 00 00 02 d6 00 26 51 cc f9 41 08 00        ...
....&Q..A..
The jump server's address is 172.24.8.30 and TEST's IP is 10.17.1.156. This is what leads me to believe that the problem is with the SLES 12 system installed on TEST. Linux is displaying messages showing that the request is reaching the IP stack. Note that this problem exists whether or not SuSEFirewall2 is running. There isn't anything about this request being logged in /var/log/firewall.

Any ideas on what I need to change to resolve this?


Harley