Menu
▾
▴
#19 1.8 filters packets that should pass
We think it's a problem with the old ipfilter version that is used in the 1.8 version (m0n0wall was affected the same way).
The firewall drops incoming packets that are coming from an ipsec vpn connection. The server (172.31.33.38) was called on the same port (56208) before and his response was dropped.
15:30:45.850420 enc0 @0:29 b 172.31.33.38,56208 -> 10.3.21.129,26737 PR tcp len 20 40 -AR IN OOW
The rules permit these packets.
oh, and thanks a lot for working on the much more recent 1.10 version
what version was this experianced on , and can you post the contents of status.php ?
This happens for example on Version 1.8.2b71 (which is currently used)
Thanks for posting status.php. nothing obvious there.
How frequently does this happen/ how repreducable is it / what operating systems are client / server ?
This happens to all packets from this port from this server. There should be some kind of telnet communication on this port. Other ports work.
I don't really know much about the server. It identifies as Linux (amd64) 3.0.101-0.47.67-xen
The client is running windows 7.
This also happens in the 1.10 branch (b91)
Last edit: Jens Pickenpack 2016-01-18
now that your are on 1.10 ...
how can I replicate this problem , open a telnet connection from a client on one side to a server on the other, check it works, then wait for an error , or disconnect or after some time try to send commands and they fail ?
Hi Jens, how easily can you replicate this problem ?
OOW means out of window, and this shouldn't happen. It can happen if the state was created without it knowing the window size etc. This can happen if the state was created by a packet other than the initial SYN packet.
Looking at how t1n1wall and m0n0wall builds firewall rules, It doesn't keep state specifically on SYN packets, which could be the problem. However it's not a super simple thing to change, as the rules interface doesn't allow flags to be set.
I could not replicate the problem.
I tried to sniff the communication that occures with other comparable sap netweaver portals which I can deploy on.
They did not even try to reach me on Port 56208, but on 56213.
It's very strange...
The only way I can think to replicate this issue, is to have a server and client that has windows scaling enabled (usually is by default) and have them establish a connection.
there should be a firewall state entry created for this session at this point. that entry will be aware of the windows scaling factor that is indicated in the SYN.
now flush the firewall state, while the connection is established, and try send a packet between client and server. the rules will create a new state entry, but as this is not a SYN will not have the windows scaling factor, and hopefully will give an OOW message. But why would you be experiancing firewall states that don't have the scaling factor, that is the real question. Looking at the rules, I don't see why you must have this state, the rules create state from any packet, not just SYN packets. however, as all tcp must start with a SYN, why would it not create it based on that packet ....
is the connection idle for a long time ? like 5 hours or more ?
No it's a fresh connection.
Would it help if we gave you remote access to our network?
Hi, I'd prefer not to access you network, the security implications are too great for now.
Can you change your ipsec ipv4 rules, so that before the permit any, is a permit specific to this traffic, with logging enabled ? i'd like to see the output of the permit.
from your previous notes, can you confirm
1) the client never successfully connects to the server on port 56208 ?
2) normally traffic is on server port 56213
3) the client can connect to other ports on that server
your log blocked line
15:30:45.850420 enc0 @0:29 b 172.31.33.38,56208 -> 10.3.21.129,26737 PR tcp len 20 40 -AR IN OOW
indicates it was a Reset from the server to the client. Can you get a client side tcpdump ?
I don't know SAP, but thinking about this, the client is getting its configuration from somewhere that is giving it the wrong port number, and that port is sending a RST back to the client. How does the client know what server and port to connect to ? could it be DNS SRV record or Active Directory / LDAP ?
Hi, any update here, can you read my previous updates ?
We replaced our firewall with a Cisco one.
The client knows what ports to use by the instance number of the server you have to know before connecting. It's described here: https://help.sap.com/saphelp_nw73/helpdata/en/a2/f9d7fed2adc340ab462ae159d19509/content.htm
Thanks for you support
I'm closing this as I can't replicate it, and the reporter has replaced t1n1wall with a cisco firewall