> -----Original Message-----
> From: André Warnier [mailto:a...@ice-sa.com]
> Sent: Monday, January 20, 2014 2:41 PM
> To: Tomcat Users List
> Subject: Re: Cannot connect from outside using Tomcat 7/APR/SSL on AWS
> Windows system
>
> Jeffrey Janner wrote:
> >> -----Original Message-----
> >> From: André Warnier [mailto:a...@ice-sa.com]
> >> Sent: Monday, January 20, 2014 1:47 PM
> >> To: Tomcat Users List
> >> Subject: Re: Cannot connect from outside using Tomcat 7/APR/SSL on
> >> AWS Windows system
> >>
> >> Jeffrey Janner wrote:
> >>>> -----Original Message-----
> >>>> From: André Warnier [mailto:a...@ice-sa.com]
> >>>> Sent: Monday, January 20, 2014 11:01 AM
> >>>> To: Tomcat Users List
> >>>> Subject: Re: Cannot connect from outside using Tomcat 7/APR/SSL on
> >>>> AWS Windows system
> >>>>
> >>>> Jeffrey Janner wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: André Warnier [mailto:a...@ice-sa.com]
> >>>>>> Sent: Monday, January 20, 2014 10:09 AM
> >>>>>> To: Tomcat Users List
> >>>>>> Subject: Re: Cannot connect from outside using Tomcat 7/APR/SSL
> >>>>>> on AWS Windows system
> >>>>>>
> >>>>>> Jeffrey Janner wrote:
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Ognjen Blagojevic [mailto:ognjen.d.blagoje...@gmail.com]
> >>>>>>>> Sent: Sunday, January 19, 2014 9:19 AM
> >>>>>>>> To: Tomcat Users List
> >>>>>>>> Subject: Re: Cannot connect from outside using Tomcat
> 7/APR/SSL
> >>>>>>>> on AWS Windows system
> >>>>>>>>
> >>>>>>>> Jeffrey,
> >>>>>>>>
> >>>>>>>> On 19.1.2014 6:03, Christopher Schultz wrote:
> >>>>>>>>>> <Connector address="10.4.1.20" port="443"
> >>>> maxHttpHeaderSize="8192"
> >>>>>>>>> Could it be as simple as having set the "address" attribute?
> >>>>>>>> +1
> >>>>>>>>
> >>>>>>>> BTW, setting attribute preverIPv4Stack=true on server side
> >>>>>>>> doesn't mean anything for the client. The client will try to
> >>>>>>>> connect with
> >>>>>> the
> >>>>>>>> protocol he prefers. The client may also fall back to other
> >>>>>>>> protocol (e.g. if IPv6 connection fails several times, try
> with
> >>>> IPv4).
> >>>>>>>> I see that access log is not configured. Is there a reason for
> >>>> that?
> >>>>>>>> Without access log you can't tell if the remote request
> reaches
> >>>>>>>> Tomcat or not. So, for start, I suggest you configure access
> >>>>>>>> log for Tomcat 7 and report back if something is logged after
> >>>>>>>> you
> >> try
> >>>>>>>> to connect from the remote host. Note that Tomcat may postpone
> >>>>>>>> writes
> >>>>>> to
> >>>>>>>> the log files, so make sure you stop Tomcat before you check
> >> your
> >>>>>> logs.
> >>>>>>>> If there is no record of remote requests in Tomcat 7 access
> >> logs,
> >>>> I
> >>>>>>>> suggest you analyze what is going on with Wireshark or some
> >> other
> >>>>>>>> packet analyzer. You can that see if the client:
> >>>>>>>>
> >>>>>>>> 1. tries to connect using IPv6 or IPv4, 2. is falling back, 3.
> >>>>>>>> which exactly IPv4/v6 adress does it use, 4. is TCP three-way
> >>>>>>>> handshake successfull.
> >>>>>>>>
> >>>>>>>> Only when you confirm that three-way handshake is succsessful
> >> and
> >>>>>>>> that the destionation IP adress is IPv4 "10.4.1.20", you may
> >>>>>>>> say
> >>>>>> that
> >>>>>>>> the request should have reached Tomcat.
> >>>>>>>>
> >>>>>>>> -Ognjen
> >>>>>>> Added the access log. Absolutely 0 entries from any address
> >>>>>>> that
> >>>> is
> >>>>>> not the local system.
> >>>>>> Can you configure your Tomcat-6 to run under your Java-7 ?
> >>>>>> (in the principle, I think that this should work; I don't know
> >>>>>> about the practice) This would help determine if the difference
> >>>>>> resides in the Java or the Tomcat.
> >>>>>>
> >>>>> Tried it a different way. Since TC7 is supposed to support Java
> >>>>> 1.6,
> >>>> switched my TC7 to use the existing Java6.
> >>>>> No luck.
> >>>>> Noticed that 7.0.47 is old now. Going to try 7.0.50.
> >>>>>
> >>>> Did you try a simple :
> >>>>
> >>>> telnet 10.4.1.20 <Tomcat listen port>
> >>>>
> >>>> (just to see if 'anything' from outside can connect to your
> >>>> AWS/Tomcat
> >>>> port)
> >>>>
> >>> Nope, just timeouts.
> >> If the connection is not rejected right away with a "connection
> >> refused by host", it normally means that a LISTEN port is opened on
> that port.
> >>
> >> Taken "strictly by the book" and according to your presumed accurate
> >> description of the symptoms above,
> >>
> >> A timeout suggests to me that the connection request packet (SYN ?)
> >> is received and accepted by the server, but that the return packet
> >> which should tell the client so (ACK ?), never makes it back to the
> client.
> >> Hence the client waits, until the timeout kicks in.
> >>
> >> Are you sure that this server has a route back to the client ?
> >>
> >> Or, are you sure that your descriptions so far are really accurate ?
> >> For example, is it really the same server on which you can make this
> >> succeed/fail just by switching the Java and/or Tomcat version, no
> >> other changes involved ?
> >> (Also see Konstantin's question about the apparent discrepancy
> >> between the netstat output and your server.xml).
> >>
> > Yep, just stopping one service and starting the other. It's
> something weird with the server, since an identical Tomcat 6 install
> wouldn't work with a copied and stripped configuration. I'm double-
> checking everything, but I think the server's tied the outside IP to
> the wrong internal IP. Trying to come up with a way to check that.
> > Note, the connectors and hosts my original posted server.xml are
> taken from my original install, but that also has another pair of
> connectors (different IPv4 address) and some hosts that should only
> respond on that address, though they are all under one service/engine
> combo. The troublesome address connectors and hosts are commented out
> in the original and the original restarted before I try to start the
> newer setups.
> >
>
> Suggestion: read Part III of the article which I mentioned earlier
> (http://www.excelsior-usa.com/articles/tomcat-amazon-ec2-basic.html),
> particularly the section "Assigning an Elastic IP Address".
>
> It suggests that there is a lot more going on with AWS instances than
> merely tying up a socket to an IP address. I don't know really, but
> maybe it is something in that area which stymies your attempts..
>
> In the meantime, I'll go back to your quoted server.xml (the
> <Connector> entries), and see if yomething there catches my
> imagination.
> What I am thinking of, is some edge case between the AWS IP-binding
> logic, and APR socket configuration. After all, it is quite possible
> that not all such cases would have been thoroughly tested, and you may
> have stumbled inadvertently on one such.
>
Forgot to mention that I am using EIP for all mappings. I'm not depending on
"magic" from AWS.
Also, I'm working under Windows, but the basics are the same.
