> -----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.
>
Thanks for looking. If it will help, the IP I'm using is the "Primary" for the
Elastic Network Interface, with the mapping that is assigned to it. I'm Remote
Desktopping to the external IP on the Primary when doing the work and it never
goes away. I can stop & restart the existing Tomcat 6 all I want with now
problems. I can even delete & recreate it, provided I recreate the full setup
(both internal IPs across 4 connectors). Making me think something not mapping
correctly in the AWS setup.
