search for: sourceports

On 28 January 2017 at 13:44, Mike McCarthy, W1NR <sysop at w1nr.net> wrote: > firewalld isn't the only thing that will prevent services from accessing > the internet. I found that I needed to do a relabel before postfix could > access DNS and I have seen other issues as well. Have you tried > disabling the firewall to see if you can get connections to work? Then > try to

.... Clearly, below, those services and ports are open as well as mysql. Ouput from: firewall-cmd --list-all-zones work target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client ssh urbackup-server ports: protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules: drop target: DROP icmp-block-inversion: no interfaces: sources: services: ports: protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules: internal (active) target: default icmp-block-inversion: no in...

Hi, We couldn't delete any files and directories when connecting glusterfs to windows via NFS. We could make/change files and directories. Although it has written that glusterfs can be connected with windows NFS client in the page shown below. Any ideas to workaround/fix this ?

...tp http https imaps pop3s smtp ssh ports: 110/tcp 21/tcp 20000/tcp 106/tcp 53/tcp 990/tcp 5432/tcp 8447/tcp 113/tcp 143/tcp 3306/tcp 5224/tcp 22/tcp 465/tcp 995/tcp 25/tcp 10000/tcp 8443/tcp 993/tcp 443/tcp 8880/tcp 587/tcp 20/tcp 53/udp 12768/tcp protocols: masquerade: yes forward-ports: sourceports: icmp-blocks: rich rules: But by ss -nat, IPV4 443 is not listend. How can I fix? # ss -nat | grep LISTEN | grep 443 LISTEN 0 128 :::443 :::* Tadao

the establishment of an openvpn link sometimes fails. I tracked it down to network traffic with wrong Sourceport in the answer packet (should be 1300 not 1024): 2 1.119309000 aaa.185.165 bbb.162.192 UDP 58 Source port: 1300 Destination port: 1300 3 1.119446000 bbb.162.192 aaa.185.165 UDP 66 Source port: 1024 Destination port: 1300 and a collateral entry in the connection tracking table

...tp http https imaps pop3s smtp ssh ports: 110/tcp 21/tcp 20000/tcp 106/tcp 53/tcp 990/tcp 5432/tcp 8447/tcp 113/tcp 143/tcp 3306/tcp 5224/tcp 22/tcp 465/tcp 995/tcp 25/tcp 10000/tcp 8443/tcp 993/tcp 443/tcp 8880/tcp 587/tcp 20/tcp 53/udp 12768/tcp protocols: masquerade: yes forward-ports: sourceports: icmp-blocks: rich rules: Now I can use http normally. And 'ss -nat' shows 80 ports used. But in avobe firewalld lists, there's http service, but isn't 80/tcp.port. Must I add 80/tcp.port? Tadao 2017-07-28 11:29 GMT+09:00 Gordon Messmer <gordon.messmer at gmail.com>...

I have a new pcap from beginning to the end with openldap "TLS negoiation failed" https://gwarband.de/openldap/tracefile.dump The sourceports are 45376 and 45377 Tobias Am 2017-03-20 19:59, schrieb Aki Tuomi: > Well, those actually *reduce* the possible algorithms that can be > used, so uncommenting those can make things worse. > > Anyways, your pcap seems incomplete, can you try again? > > Aki > >> On Mar...

...t; > Aki > >> On March 20, 2017 at 9:24 PM info at gwarband.de wrote: >> >> >> I have a new pcap from beginning to the end with openldap "TLS >> negoiation failed" >> >> https://gwarband.de/openldap/tracefile.dump >> >> The sourceports are 45376 and 45377 >> >> Tobias >> >> Am 2017-03-20 19:59, schrieb Aki Tuomi: >>> Well, those actually *reduce* the possible algorithms that can be >>> used, so uncommenting those can make things worse. >>> >>> Anyways, your pcap seems...

On Thu, Nov 28, 2013 at 10:24 PM, Celelibi <celelibi at gmail.com> wrote: > 2013/11/29, Gene Cumm <gene.cumm at gmail.com>: >> On Thu, Nov 28, 2013 at 9:47 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >>> On Thu, Nov 28, 2013 at 9:34 PM, Celelibi <celelibi at gmail.com> wrote: >>>> Without an assigned source port, Transmit function assign a

...ssh > ports: 110/tcp 21/tcp 20000/tcp 106/tcp 53/tcp 990/tcp 5432/tcp 8447/tcp > 113/tcp 143/tcp 3306/tcp 5224/tcp 22/tcp 465/tcp 995/tcp 25/tcp 10000/tcp > 8443/tcp 993/tcp 443/tcp 8880/tcp 587/tcp 20/tcp 53/udp 12768/tcp > protocols: > masquerade: yes > forward-ports: > sourceports: > icmp-blocks: > rich rules: > > But by ss -nat, IPV4 443 is not listend. How can I fix? > > # ss -nat | grep LISTEN | grep 443 > LISTEN 0 128 :::443 :::* Just because the firewall is open doesn?t mean the process listening on port 443...

...ports: 110/tcp 21/tcp 20000/tcp 106/tcp 53/tcp 990/tcp 5432/tcp 8447/tcp > 113/tcp 143/tcp 3306/tcp 5224/tcp 22/tcp 465/tcp 995/tcp 25/tcp 10000/tcp > 8443/tcp 993/tcp 443/tcp 8880/tcp 587/tcp 20/tcp 53/udp 12768/tcp > protocols: > masquerade: yes > forward-ports: > sourceports: > icmp-blocks: > rich rules: > > Now I can use http normally. > And 'ss -nat' shows 80 ports used. > > But in avobe firewalld lists, there's http service, but isn't 80/tcp.port. > Must I add 80/tcp.port? > > Tadao Hi, you can define rule ei...

...ewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: ens192 tun0 sources: services: ctc-custom dhcpv6-client ssh ports: 8081/tcp 3127/tcp 3128/tcp 8080/tcp protocols: masquerade: yes forward-ports: port=80:proto=tcp:toport=3127:toaddr=1.1.1.1 sourceports: icmp-blocks: rich rules: rule family="ipv4" source address="2.2.2.0/26" protocol value="gre" accept [root at s0989-stocac1 ~]# firewall-cmd --direct --get-all-rules ipv4 nat POSTROUTING 0 -j MASQUERADE ipv4 nat PREROUTING 0 -i tun0 -p tcp -m tcp --dport...

...cating a VERY early problem with SSL handshake. Aki > On March 20, 2017 at 9:24 PM info at gwarband.de wrote: > > > I have a new pcap from beginning to the end with openldap "TLS > negoiation failed" > > https://gwarband.de/openldap/tracefile.dump > > The sourceports are 45376 and 45377 > > Tobias > > Am 2017-03-20 19:59, schrieb Aki Tuomi: > > Well, those actually *reduce* the possible algorithms that can be > > used, so uncommenting those can make things worse. > > > > Anyways, your pcap seems incomplete, can you try aga...

Hi, On some SIP interconnects with devices like Cisco, Dialogic we get SIP invite from different source port every time and asterisk rejects that INVITE. Does anyone knows solution for this? --- Kind Regards, Deepika Nijhawan VoIP Engineer Oxygen8 Communications T: +44(0) 871 434 9151 +44(0) 121 620 9151 Email: deepika.nijhawan at oxygen8.com Skype:

Hi, The question I have is regarding separated ports for client and source connections. Let me explain. Since a short while I have been successfully testing icecast and ogg for live broadcasts. Now I am building a website around it, which of course I want to be dynamically generated on the fact whether there is a live broadcast or not. The easy way I want to do that is to check for connections

...On March 20, 2017 at 9:24 PM info at gwarband.de wrote: >>> >>> >>> I have a new pcap from beginning to the end with openldap "TLS >>> negoiation failed" >>> >>> https://gwarband.de/openldap/tracefile.dump >>> >>> The sourceports are 45376 and 45377 >>> >>> Tobias >>> >>> Am 2017-03-20 19:59, schrieb Aki Tuomi: >>>> Well, those actually *reduce* the possible algorithms that can be >>>> used, so uncommenting those can make things worse. >>>> >>>...

I have also tested with 2.2.28 and this version has the same issue. The finding of compatible ciphers is not the problem because I have uncommented the ldap entrys: TLSCipherSuite SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM TLSProtocolMin 3.1 Maybe you have further ideas. Am 2017-03-20 17:42, schrieb Aki Tuomi: >> On March 20, 2017 at 5:28 PM

Hi guys, I have re-implemented /efi/udp.c The new code fixes: 1) The low and decreasing throughput on TFTP transfers. 2) The added delay between consecutive TFTP transfers. 3) The TFTP errors induced by broadcast traffic like ARP. Initial tests on a 50MB transfer showed times going from 3 minutes to ~12 seconds, also tested OK with nested TFTP transfers (include command). This

On Thu, Nov 28, 2013 at 9:47 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Thu, Nov 28, 2013 at 9:34 PM, Celelibi <celelibi at gmail.com> wrote: >> Without an assigned source port, Transmit function assign a random new >> source port to the packet being sent. It thus have to be set before >> calling Transmit if the source port have already been decided.

The variable 'ok' is never used and generates a warning. Remove it. Also ntfssect.c is designed to be compiled in non Unicode mode when using MSVC compilers, so remove all ambiguity about it (LPCTSTR -> LPCSTR, use of 'A' API calls) so that it doesn't break when compiled in Unicode mode, which is what Rufus uses with MSVC. -------------- next part --------------