WireGuard not connecting to the Internet - server

WireGuard server seems not to be forwarding connection to the Internet.
I tried re-installing from scratch Wireguard on both my computer and my server, but the problem remained.
When I sudo wg-quick up wg0-client, I get:
[#] wg setconf wg0-client /dev/fd/63
[#] ip address add 10.200.200.2/32 dev wg0-client
[#] ip link set mtu 1420 up dev wg0-client
[#] resolvconf -a tun.wg0-client -m 0 -x
Too few arguments.
Too few arguments.
[#] wg set wg0-client fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0-client table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
Here are my /etc/wireguard/wg0.conf (on my server)...
[Interface]
Address = 10.200.200.1/24
SaveConfig = true
PrivateKey = server_private_key
ListenPort = 51820
[Peer]
PublicKey = client_public_key
AllowedIPs = 10.200.200.2/32
... and my /etc/wireguard/wg0-client.conf (on my machine):
[Interface]
Address = 10.200.200.2/32
PrivateKey = client_private_key
DNS = 10.200.200.1
[Peer]
PublicKey = server_public_key
Endpoint = server_address:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 21
I guess the lines with -4 and Too few arguments may hold the key to the problem, but I know too little about this kind of things to figure it out myself. Of course I didn't forget to wg-quick up wg0 on my server.

Too few arguments is just a warning, I met a same issue and the connection is okay. Someone is saying it's an issue of resolvconf in a resolvconf bug.
You are able to try again with scripts in wireguard scripts.

Make sure you create the following file using a text editor too:
vim /etc/sysctl.d/10-wireguard.conf
Add the following text:
`
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
Reload all changes and turn on NAT routing:
sysctl -p /etc/sysctl.d/10-wireguard.conf
systemctl restart wg-quick#wg0.service
`

Related

openvswitch refuses to forward packets between interfaces

I have an openvswitch instance that refuses to forward packets between two interfaces.
First of all i disabled other_config dpdk-init. Now there are no other_config values in Open_vSwitch table.
Next I created a new bridge. And only added the PF (physical) interfaces. These interfaces are tagged currently on the same vlan and were configured with netplan.
$ip -br a | grep 3935
enp65s0f1.3935#enp65s0f1 UP fe80::63f:72ff:feea:ca55/64
enp65s0f0.3935#enp65s0f0 UP fe80::63f:72ff:feea:ca54/64
I then removed the dpdk ports from ovs and created a new bridge. Then added the PF interfaces as NON dpdk interfaces. I did not tag these interfaces on OVS, as the interfaces are tagging via netplan. Note: I did try tagging the interfaces as well even though they are already tagged from netplan, did not help.
$ sudo ovs-vsctl add-br br0
$ sudo ovs-vsctl add-port enp65s0f0.3935
$ sudo ovs-vsctl add-port enp65s0f1.3935
$ sudo ovs-vsctl show
e2a3fa00-23c9-4c3d-b9b6-e37df4f00dd7
Bridge br0_dpdk
datapath_type: netdev
Port br0_dpdk
Interface br0_dpdk
type: internal
Bridge br0
Port enp65s0f0.3935
Interface enp65s0f0.3935
Port enp65s0f1.3935
Interface enp65s0f1.3935
Port ovsmi175332
Interface ovsmi175332
Port ovsmi138678
Interface ovsmi138678
Port br0
Interface br0
type: internal
ovs_version: "2.17.2"
Then I started sending traffic. I can now see traffic being RX on the inbound interface (enp65s0f0.3935) from OVS standpoint.
$ sudo ovs-ofctl dump-ports br0 enp65s0f0.3935
OFPST_PORT reply (xid=0x4): 1 ports
port "enp65s0f0.3935": rx pkts=7299742, bytes=435598113, drop=0, errs=0, frame=0, over=0, crc=0
tx pkts=2826, bytes=3288309, drop=0, errs=0, coll=0
I also was able to use ovs-tcpdump -i enp65s0f0.3935 and I saw traffic. So I know the OVS port is RX traffic.
I checked the forwarding table for OVS and I see MAC addresses coming from the RX interface.
$ sudo ovs-appctl fdb/show br0 | head -n 10
port VLAN MAC Age
22 0 02:1a:c5:03:00:0f 0
22 0 02:1a:c5:03:00:17 0
22 0 02:1a:c5:03:00:15 0
22 0 02:1a:c5:03:00:24 0
22 0 02:1a:c5:03:00:0c 0
22 0 02:1a:c5:03:00:2a 0
22 0 02:1a:c5:03:00:0b 0
22 0 02:1a:c5:03:00:33 0
22 0 02:1a:c5:03:00:40 0
And here is the flow output from both interfaces
$ sudo ovs-appctl ofproto/trace br0 "in_port=22"
Flow: in_port=22,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
bridge("br0")
-------------
0. priority 0
NORMAL
-> no learned MAC for destination, flooding
Final flow: unchanged
Megaflow: recirc_id=0,eth,in_port=22,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Datapath actions: 4,1,3,5
$ sudo ovs-appctl ofproto/trace br0 "in_port=23"
Flow: in_port=23,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
bridge("br0")
-------------
0. priority 0
NORMAL
-> no learned MAC for destination, flooding
Final flow: unchanged
Megaflow: recirc_id=0,eth,in_port=23,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000
Datapath actions: 5,1,2,4
However No traffic is being TX from enp65s0f0.3935 to enp65s0f1.3935.
Why is traffic being refuses to be forwarded? What am I missing?
EDIT:
I did another test where I tested two name spaces linked to the OVS using a different bridge. Doing this I am able to ping across the OVS system between the two name spaces with no problems. Problem seems to be with the physical interfaces. Note these are Mellanox interfaces.

Confuse about fail2ban behavior with firewallD in Centos 7

I was using fail2ban/iptables in a Centos 6 server.
I moved to Centos 7 and now I am using fail2ban/firewallD (installed by Webmin/Virtualmin with their defaults)
These are cat /var/log/maillog | grep "disconnect from unknown" screen shots
cat /var/log/fail2ban.log | grep Ban only displays
2019-10-27 16:52:22,975 fail2ban.actions [8792]: NOTICE [proftpd] Ban 111.225.204.32
Furthermore tailf /var/log/fail2ban.log displays several "already banned" of the same IP. In this case fail2ban, after maxretry is reached it tries to ban the IP.
Here are my configurations (partial), I left them as they were by defaults but changed bantimes.
jail.local
[postfix]
enabled = true
port = smtp,465,submission
bantime = -1
[postfix-sasl]
enabled = true
port = smtp,465,submission,imap3,imaps,pop3,pop3s
bantime = -1
[dovecot]
enabled = true
port = pop3,pop3s,imap,imaps,submission,465,sieve
bantime = -1
jail.conf
[DEFAULT]
findtime = 600
maxretry = 5
backend = auto
filter = %(__name__)s
port = 0:65535
banaction = iptables-multiport
banaction_allports = iptables-allports
action_ = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="% > (port)s", protocol="%(protocol)s", chain="%(chain)s"]
action = %(action_)s
jail.d/00-firewalld.conf
[DEFAULT]
banaction = firewallcmd-ipset
These files exist: action.d/firewallcmd-ipset.conf and filter.d/postfix.conf
firewall-cmd --direct --get-all-rules
ipv4 filter INPUT_direct 0 -p tcp -m multiport --dports ssh -m set
--match-set fail2ban-default src -j REJECT --reject-with icmp-port-unreachable
ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable
ipv4 filter INPUT 0 -p tcp -m multiport --dports 10000 -m set --match-set fail2ban-webmin-auth src -j REJECT --reject-with icmp-port-unreachable
ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh,sftp -m set --match-set fail2ban-ssh-ddos src -j REJECT --reject-with icmp-port-unreachable
After manually running
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='193.56.28.0/24' reject"
and
firewall-cmd --reload this output of tailf /var/log/fail2ban.log
stopped.
How can I get all those IPs banned after they reach maxretry value?
Would they be banned forever despite service restart or reload?
Edit 1:
From fail2ban.log with action=firewalld-cmd ipset
From fail2ban.log with action=iptables-allports
Edit 2:
It seems (I guess) something is flushing configurations (I guess it would be Webmin) because after a while I start getting error logs like failed to execute ban jail 'dovecot' action iptables-allports so I am trying this:
in actions.d created banning.conf
[Definition]
actionban = /usr/bin/firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='<IP>' reject"; ; /usr/bin/firewall-cmd --reload
and at jail.local
[DEFAULT]
banaction = iptables-multiport
banning
But I get Error in action definition banning
I know this is not a solution.
Before moving the server I was using fail2ban/iptables (not firewalld) for years not having to pay attention beyond default settings.
How can I get all those IPs banned after they reach maxretry value?
Your issue has probably nothing with maxretry etc.
If you see [jail] Ban 192.0.2.1 and several [jail] 192.0.2.1 already banned messages hereafter (especially after some minutes after the "Ban" message for same Jail/IP), this means only that your banning action (firewalld) does not work at all (after ban, the intruder-IP is still able to repeat its attempts).
In the last time we had certain issues with that (especially with combination firewalld + CentOS) - see for example https://github.com/fail2ban/fail2ban/issues/1609 as well as related firewalld issue - https://github.com/firewalld/firewalld/issues/515.
So check your native net-filter (iptables, etc), if you see some (white-listing established traffic) rules before fail2ban chains, it looks like your configuration is not fail2ban (or whatever banning-system) capable... here may be the answer for you - https://github.com/fail2ban/fail2ban/issues/2503#issuecomment-533105500.
Here is another similar issue with an example excerpt illustrating "wrong iptables rule that bypass fail2ban" - https://github.com/fail2ban/fail2ban/issues/2545#issuecomment-543347684
In this case:
either switch the backend of firewalld (as suggested above);
or switch the banaction of fail2ban to something native (iptables/ipset/etc).
or even add still one action dropping or killing active established connection of the banned IP (using something like tcpkill, killcx, ss etc).
UPDATE 1
jail.local example:
[DEFAULT]
banaction = iptables-multiport
banaction_allports = iptables-allports
[postfix-sasl]
enabled = true
[dovecot]
enabled = true
...
If after fail2ban reload you'd still see some IP making attempts after ban and already banned in fail2ban.log, provide log-excerpt of fail2ban by the first ban or else some possible errors around (because already banned is too late and does not help at all).
If no errors are there, provide output of iptables -nL.

FreeRadius - Failed binding to authentication address

When I run the following command, I can get successfull result.
root#ubuntu:/home/can# radtest user password 127.0.0.1 1812 testing123
Sending Access-Request of id 78 to 127.0.0.1 port 1812
User-Name = "user"
User-Password = "password"
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=78, length=20
However When I run the "freeradius -X" , I get error message as following :
.....
Failed binding to authentication address * port 1812: Address already in use
/etc/freeradius/radiusd.conf[250]: Error binding to port for 0.0.0.0 port 1812
Please Help Me
Thank you for your efforts.
Can
radiusd is already running. sudo service freeradius stop will stop it, and allow freeradius -X to bind to the address/port that was previously used by the RADIUS daemon.
Run 'service freeradius restart' and 'service freeradius stop' commands
Then run the command,'freeradius -X'
you will not face binding issue anymore.
Even having finished the service, there were pending zombie process.
Searching for a zumbi process I´ve found one:
[root#localhost sites-enabled]# ps aux | grep radi
radiusd 25042 0.0 0.7 186360 14980 ? Ssl Fev17 0:00 /usr/sbin/radiusd -d /etc/raddb
[root#localhost sites-enabled]# kill -9 25042
Service was start sucessfully after this.
Basically the port freeradius is looking to use is already in use by another background running instance of freeradius. Ending the first instance of freeradius will allow you to use that same port for the newly run instance.

Bonjour: Can not ping through serviceName on Windows

I develop our application and can succeed to get hotsname through func: ServiceFound(DNSSDService sref, DNSSDFlags flags, uint ifIndex, String serviceName, String regType, String domain)
I checked the wireshark and Log, the serviceName is right.
My question:
Why I can not ping it through "serviceName.domain", e.g: ping serviceName.local. (I want to use ping to test the network available beofre run my application. now it is blocked the failed ping)
But I can ping it through the real IP, e.g: ping 1.2.3.4 (This means that the network is ok)
ServiceFound and ServiceResolved only provide serviceName.
So how to solve this problem:
1) one simple way to get IP
or 2) how to solve the problem of "ping serviceName.local"
Thanks a lot for your support in advance!
************************Update*******
I retest it on other PC:
I use dns-sd.exe to debug the network
Using following command can get servicename
$ dns-sd.exe -B _http._tcp
Browsing for _http._tcp
Timestamp A/R Flags if Domain Service Type Instance Name
4:33:52.663 Add 3 3 local. _http._tcp. test
Using following command can get zone file
$ dns-sd.exe -Z _http._tcp
Browsing for _http._tcp
_http._tcp PTR Officejet\032Pro\032L7500\032[FEDCE8]._http._tcp
Officejet\032Pro\032L7500\032[FEDCE8]._http._tcp SRV 0 0 80 HPFEDCE8.local. ; Replace with unicast FQDN of target host
Officejet\032Pro\032L7500\032[FEDCE8]._http._tcp TXT ""
using following command can get IP (based on HPFEDCE8.local. in above feedback)
$ dns-sd.exe -G v4 HPFEDCE8.local.
Timestamp A/R Flags if Hostname Address TTL
4:43:38.965 Add 2 3 bej1301Dell2360.local. 10.61.20.99 240
So I can ping it through HPFEDCE8.local.
But in my Test PC: "$ dns-sd.exe -B _http._tcp" is ok, but others commands are failed.
So I think this is the root cause.
So my question is:
as I know, we can use "instance Name" to generate the hostname: test.local.
why they are different from "HPFEDCE8.local." in the zone file
why "ping HPFEDCE8.local." ok and "ping test.local." failed
Do you have any others ideas for my Test PC?
Thanks a lot!!

CentOS 6.3 Samba share over internet not working

Summary:
This is a 2 part question. A simple Samba share on one ISP with router doesn't work while another ISP with a different router setup the same and a similar server with same Samba configuration works.
It seems to be either the router not forwarding the ports, although it successfully forwards SSH and others, or the ISP somehow blocking the standard Samba ports. It still bugs me that I can't figure out why it doesnt work and I'll still try to narrow down the cause.
The second question is I'm looking for a business use, simple, easy to use (for end users), secure share for a small number of people and files, hosted internally and accessible externally on the internet, between Windows 7, XP, Mac, and linux servers with simple clients for end users.
A new friend outside of stackoverflow helped with sshfs as a solution. On CentOS ssh already supports sshfs. The Windows client win-sshfs is working well and I'll be trying OSXFUSE with MACFusion described at UO.
Additionally, setup linux users for each person. To allow write by everyone in the linux group, change the umask in /etc/ssh/sshd_config described in this question at serverfault. People get to their home directory first, where I placed links to a shared folder with sticky bit set so they can't delete the folder. They can delete the links but that's easy enough to put back. The only issues I can see are lack of file locking and lack of auto-refresh.
Original Question:
I can't seem to get Samba working on a Centos 6.3 server over the internet. I have a similar test server on another internet connection working fine with the exact same setup. I've gone through http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/diagnosis.html twice, made sure the ports are forwarded through to the internet (although not sure how to test they are really open), double checked samba configuration, its only sharing /tmp simply now. The user account is setup, it can ssh in and get to /tmp and the samba password is set the same. I can't ping the server but that is because the router or IP is set not pingable by the owner/work. SSH and HTTPS apache work well on the server with ports forwarded the same way. I haven't been able to test the share within the local network yet since I am not there, but I assume that it should work internally. When trying to connect from Windows 7 it just times out, no prompt and it has never connected, whereas my test server on my own internet connection is always working internally and externally.
Any help would be greatly appreciated.
The requirement is a easy to use internally hosted shared folder alternative to using "dropbox" for use between Windows 7, XP, mac, and linux servers that works over external internet connection. It won't see heavy usage but should be quick, easy to access/setup on the client side, and secure for business. If there are any alternatives to install on CentOS that would be great as well.
Thank you!
Andrew
Edit, details:
Ports are forwarded:
(I had an image but as new user I cant post) 137, 138, 139, 445 are forwarded all with both TCP and UDP for testing now.
smb.conf is setup simply and exactly the same as the working test server:
# cat /etc/samba/smb.conf
[global]
workgroup=WORKGROUP
log level = 3
log file = /var/log/samba/log.%m
max log size = 50
security = user
passdb backend = tdbsam
[tmp]
comment = temporary files
path = /tmp
read only = yes
Samba restarted for good measure:
# service smb restart
Shutting down SMB services: [ OK ]
Starting SMB services: [ OK ]
Windows 7 times out when trying to access the share as \ which works fine with the test server:
(I had a screenshot but new users cant post)
A search for the error 0x80004005 results in http://answers.microsoft.com/en-us/windows/forum/windows_vista-networking/cannot-access-network-share-get-unspecified-error/9f840844-9d5b-e011-8dfc-68b599b31bf5
I've checked the workgroup, share settings, and restarted windows. Since the test share works I would think the Windows machine is working. I'll continue with the details.
Edit again:
Following the troubleshooting guide again:
Simplify the smb.conf to just:
# cat /etc/samba/smb.conf
[tmp]
comment = temporary files
path = /tmp
read only = yes
/etc/resolv.conf is using the ISPs servers and they work. They are different than the working server's DNS but that one is on a different ISP:
# nslookup google.com
Server: 71.242.0.12
Address: 71.242.0.12#53
Non-authoritative answer:
Name: google.com
Address: 74.125.228.2
I'm doing everything with IP addresses so I don't know that DNS would come into play.
I added dns proxy = no to smb.conf for fun but that didn't help.
/var/log/samba/log.smbd doesn't report anything different from the working server:
[2012/09/20 16:59:41, 0] smbd/server.c:1141(main)
smbd version 3.5.10-125.el6 started.
Copyright Andrew Tridgell and the Samba Team 1992-2010
[2012/09/20 16:59:41.484699, 0] param/loadparm.c:7648(lp_do_parameter)
Global parameter dns proxy found in service section!
[2012/09/20 16:59:41.486645, 0] printing/print_cups.c:109(cups_connect)
Unable to connect to CUPS server localhost:631 - Connection refused
[2012/09/20 16:59:41.486809, 0] printing/print_cups.c:468(cups_async_callback)
failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
[2012/09/20 16:59:41.507198, 0] smbd/server.c:501(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use
[2012/09/20 16:59:41.507407, 0] smbd/server.c:501(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use
[2012/09/20 17:00:39, 0] smbd/server.c:1141(main)
smbd version 3.5.10-125.el6 started.
Copyright Andrew Tridgell and the Samba Team 1992-2010
[2012/09/20 17:00:39.513793, 0] printing/print_cups.c:109(cups_connect)
Unable to connect to CUPS server localhost:631 - Connection refused
[2012/09/20 17:00:39.513955, 0] printing/print_cups.c:468(cups_async_callback)
failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
[2012/09/20 17:00:39.535458, 0] smbd/server.c:501(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use
[2012/09/20 17:00:39.535689, 0] smbd/server.c:501(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use
However the working server creates a log file in the directory named log. which the non working server does not.
testparm:
# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[tmp]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
[global]
[tmp]
comment = temporary files
path = /tmp
continuing...
Continued:
nmb is running as well:
# service nmb restart
Shutting down NMB services: [ OK ]
Starting NMB services: [ OK ]
"Respond to Ping on Internet Port" is normally turned off on the routers. I turned it on, on both the Windows client and the server. Each can ping the other, sharing still doesn't work.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\xxxx>ping xxxx
Pinging xxxx with 32 bytes of data:
Reply from xxxx: bytes=32 time=25ms TTL=51
Reply from xxxx: bytes=32 time=23ms TTL=51
Reply from xxxx: bytes=32 time=26ms TTL=51
Reply from xxxx: bytes=32 time=24ms TTL=51
Ping statistics for xxxx:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 23ms, Maximum = 26ms, Average = 24ms
# ping xxxx -c 5
PING xxxx (xxxx) 56(84) bytes of data.
64 bytes from xxxx: icmp_seq=1 ttl=251 time=20.7 ms
64 bytes from xxxx: icmp_seq=2 ttl=251 time=24.6 ms
64 bytes from xxxx: icmp_seq=3 ttl=251 time=21.4 ms
64 bytes from xxxx: icmp_seq=4 ttl=251 time=25.3 ms
64 bytes from xxxx: icmp_seq=5 ttl=251 time=22.9 ms
--- xxxx ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4029ms
rtt min/avg/max/mdev = 20.776/23.022/25.319/1.764 ms
continuing...
Continued:
iptables are off:
# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
SELinux is off:
# sestatus
SELinux status: disabled
smbclient using a user setup in samba works from the samba server to its local IP and to its external IP. The Windows client gets:
Connection to <ip addr> failed (Error NT_STATUS_UNSUCCESSFUL)
Samba is running as a daemon/service and netbios-ssn is in listen mode:
# netstat -a|grep netbios-ssn
tcp 0 0 *:netbios-ssn *:* LISTEN
Continuing...
Continued:
We're not restricting connections or using inetd.
log.nmbd does not report any problems.
nmblookup -B BIGSERVER SAMBA works using the server's name
nmblookup -B ACLIENT * fails on all log files using the windows client name OR the external IP address
nmblookup -d 2 `*'. fails
"If your PC and server aren't on the same subnet, then you will need to use the -B option to set the broadcast address to that of the PC's subnet.
This test will probably fail if your subnet mask and broadcast address are not correct. (Refer to test 3 notes above)."
Im not sure here, since we're going over the internet do we need these to match and work?
smbclient //BIGSERVER/TMP works
On the client:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\xxxx>net view \\xxxx (ip addr)
System error 53 has occurred.
The network path was not found.
C:\Users\xxxx>
net use has the same problem, even with providing user and passwd.
nmblookup -M WORKGROUP returns a local windows machine on the network there, whereas on my test server it returns the client which is local to the test machine. Perhaps there is an issue here with workgroup being on another machine, but how would others connect from other networks if this was the issue?
I tried preferred master = yes as well.
Page 2 of samba howto next.
Update: A new friend said to try nmap to see check the ports:
# nmap -sS -P0 -sV -O xxxx
Starting Nmap 5.51 ( ) at 2012-09-21 11:09 EDT
Nmap scan report for xxxx (xxxx)
Host is up (0.024s latency).
Not shown: 995 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.3 (protocol 2.0)
25/tcp open smtp Postfix smtpd
110/tcp open pop3 Dovecot pop3d
443/tcp open ssl/http Apache httpd 2.2.15 ((CentOS))
9100/tcp open jetdirect?
Warning: OSScan results may be unreliable because we could not find at
least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results
incomplete
No OS matches for host
Service Info: Host: xxxx
Since the Samba ports do not show up, I'm thinking the router or ISP is not forwarding/blocking the ports at this point.
As for a solution to sharing, I'm trying sshfs with a windows and mac client.
Answering your original question, the good way to test if your ISP is not blocking listed ports is this:
# yum -y install tcpdump
# tcpdump -i eth0 "port 137 or port 138 or port 139 or port 445"
(substitute eth0 with the name of the interface connected to the Internet).
Then you should try accessing the share (net view / net use / Windows Shell). If ports are forwarded correctly you should see something like that:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
01:25:48.631173 IP 192.168.0.10.54032 > 192.168.0.1.microsoft-ds: Flags [S], seq 4008761512, win 5840, options [mss 1460,sackOK,TS val 136010468 ecr 0,nop,wscale 7], length 0
01:25:48.631198 IP 192.168.0.1.microsoft-ds > 192.168.0.10.54032: Flags [S.], seq 2220435566, ack 4008761513, win 14480, options [mss 1460,sackOK,TS val 15507714 ecr 136010468,nop,wscale 7], length 0
01:25:48.631397 IP 192.168.0.10.54032 > 192.168.0.1.microsoft-ds: Flags [.], ack 1, win 46, options [nop,nop,TS val 136010468 ecr 15507714], length 0
01:25:48.642171 IP 192.168.0.10.54032 > 192.168.0.1.microsoft-ds: Flags [P.], seq 1:184, ack 1, win 46, options [nop,nop,TS val 136010479 ecr 15507714], length 183SMB PACKET: SMBnegprot (REQUEST)
...
If you see nothing at all it means that your ISP (or intermediate router) is blocking packets to those ports and it's most likely the case — SMB protocol proved to be quite insecure for open Internet deployments.
In the file /etc/samba/smb.conf, under the section [global], below the workgroup line add this two lines :
client min protocol = NT1
client max protocol = SMB3