Muhammad, I recommend setting up the client and server, and give the entire setup/config a go. Like David said, I don't think you should have any issues doing two-way TLS auth.
On Fri, Dec 12, 2014 at 10:44 AM, David Lang <[email protected]> wrote: > > On Fri, 12 Dec 2014, Muhammad Asif wrote: > > OK. Client is on private address (so its FQDN or name is not visible on >> internet) and behind firewall and server is on public IP (on registered >> domain) and on cloud. Permittedpeer on client side will be IP or name of >> server it is clear. But what will be on server side, IP or name of >> external >> address of firewall or what. If external address of firewall then then how >> it will pass packets to client. >> > > I don't know TLS setup very well, so let me talk in terms of the > underlying protocols to explain what's happening, hopefully that will cover > the options (as opposed to just blindly trying things) > > you have client -> NAT (firewall) -> server > > to give these IP addresses and names > > client 192.168.1.2 > > inside (firewall inside) 192.168.1.1 > > firewall (firewall outside) 1.1.1.1 > > server 2.2.2.2 with RELP configured on TCP 1514 > > The client initiates a TCP connection to the server. It sees the > connection as 192.168.1.2:40000 (random high port) -> 2.2.2.2:1514 > > the packets hit the firewall, and NAT changes the TCP connection to > 1.1.1.1:50000 (random high port)-> 2.2.2.2:1514. This is what the server > sees. > > So any limits on the server that are IP based need to allow connections > from 1.1.1.1 > > The server responds by sending packets back to 1.1.1.1:50000 (packet > shows 2.2.2.2:1514 -> 1.1.1.1:50000) and the firewall NAT changes this to > 2.2.2.2:1514 -> 192.168.1.2:40000 and the packet arrives at the client. > Note that this is not a separate firewall rule, it's automatic as part of > the rule that allowed the TCP connection out from 192.168.1.2 to > 2.2.2.2:1514 > > The client then sends it's cert over the connection to the server, and the > server sends it's cert over the connection to the client > > so anything that is based on the name in the cert has to use the name of > the client (because the server is not tampering with the contents of the > connection, only the IP headers) > > > If there is a requirement that the DNS name match the cert name, then > things get messy for the client, but since NAT is so common, I don't know > of anyone who requires that the reverse DNS name matches the name in the > client cert. It is common to have this sort of requirement in the other > direction. Specifically, if the client is connecting to a server by name > and the cert that the server responds with doesn't match that name, the > client will complain or refuse to start because there could be a > man-in-the-middle attack going on. > > according to http://www.rsyslog.com/doc/v8-stable/configuration/modules/ > imrelp.html the PermittedPeer parameter is listing the fingerprint of the > certificate that the client provides, so this isn't the name or the IP > address, but rather info from the client certificate. > > Does this explain what's going on well enough? if not, let me know what > part's not clear and I'll try to clarify. > > David Lang > > > > On Thu, Dec 11, 2014 at 10:50 PM, David Lang <[email protected]> wrote: >> >>> >>> you don't need to open an inbound connection. The NAT that allows you to >>> connect out also allows the responses back in. >>> >>> David Lang >>> >>> >>> On Thu, 11 Dec 2014, Muhammad Asif wrote: >>> >>> Hi Rsyslog Users >>> >>>> >>>> My Rsyslog server is on cloud and rsyslog client in my organization on >>>> private IP. >>>> I want my rsyslog client to receive logs from internal devices and send >>>> to >>>> rsyslog server on cloud. My client is behind firewall. I want RELP on >>>> TLS >>>> between client and server. My client can access server but question is >>>> on >>>> what port rsyslog client receive acknowledgment from server so that I >>>> could >>>> do destination NAT of my firewall to reach reply from server to client. >>>> >>>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com/professional-services/ >>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you >>> DON'T LIKE THAT. >>> >>> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com/professional-services/ >> What's up with rsyslog? Follow https://twitter.com/rgerhards >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you >> DON'T LIKE THAT. >> >> _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > DON'T LIKE THAT. > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
