dorian's questions

This question is related to Apache RewriteMap with URLs containing space doesn't work, but in this case the issue is a space in the value part of the map, not the key part. Say I have this entry:

/a-normal-url/    /a-less-normal url/

As a RewriteMap's txt files are space separated, this won't work as-is. I've thus tried to escape the space:

/a-normal-url/    /a-less-normal%20url/

Unfortunately mod_rewrite will helpfully escape the redirect target, so this will lead to the request being redirected to /a-less-norma%2520url/, which also isn't what I want.

Just in case, I've also used a backslash to escape the space (/a-less-normal\ url/), but unsurprisingly this also didn't help (it will redirect to (/a-less-normal%5c) in that case.

I have a site-to-site VPN where there's one subnet on the remote side and two on the local one:

conn site-to-site
  leftsubnet = 10.10.0.0/16,10.11.0.0/16
  rightsubnet = 10.50.0.0/16

Everything works fine, but I'm having an issue where the "wrong" local IP is inserted into strongSwan's routing table:

$ ip route show table 220
    10.50.0.0/16 via <REDACTED> dev eth-ext src 10.11.0.1 

strongSwan chooses the local IP of the 10.11.0.0/16 subnet as source IP for the IPsec tunnel (i.e. 10.11.0.1), but I'd like to use the second one (10.10.0.1).

I've tried setting leftsourceip to 10.10.0.1, but that didn't seem to have an effect. Is there another configuration item I can use to tell strongSwan which local IP to use as source IP for its routing table?

This question was originally posted on the Network Engineering SE site, but closed for being off-topic.

I've stumbled upon a peculiar behavior of Windows hosts in our network.

Our clients are mostly in the wireless segment of our network. The Ubiquiti access points we use block multicast and broadcast traffic from the wired segment to the wireless segment for performance reasons.

When a host (client) on the WiFi side contacts a host (server) on the wired network that is running Linux, everything works fine. The client sends out an ARP request that is broadcast over to the wired segment, the server responds using a unicast ARP reply and learns the client's MAC address in the process. Then IP packets can be exchanged normally.

With a Windows server, however, it looks different. If I ping the server at 10.10.10.4 from the client at 10.10.244.14, I see the following packets on the server's interface:

15:11:50.892975 4c:32:75:95:b9:7b > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.10.4 tell 10.10.244.14, length 46
15:11:50.893725 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.10.10.4 is-at 52:75:9a:65:57:e4, length 46
15:11:50.898967 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 39008, offset 0, flags [none], proto ICMP (1), length 84)
    10.10.244.14 > 10.10.10.4: ICMP echo request, id 34083, seq 0, length 64
15:11:50.899285 52:75:9a:65:57:e4 > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.244.14 tell 10.10.10.4, length 46
15:11:51.711006 52:75:9a:65:57:e4 > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.244.14 tell 10.10.10.4, length 46
15:11:51.895016 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 9988, offset 0, flags [none], proto ICMP (1), length 84)
    10.10.244.14 > 10.10.10.4: ICMP echo request, id 34083, seq 1, length 64
[...]

It seems that the Windows server does not update its ARP table from the received ARP request, but sends out its own request to get the client's MAC address (as seen in the fourth packet above). These requests are broadcast and thus never reach the client. As a consequence, the pings cannot not be answered because the server does not know where to send them.

Here's the interesting part. If I keep pinging the server, after around two minutes, the ARP entry for the server on the client seems to go stale, a unicast ARP request is sent to the server to verify the cached MAC address, and from that moment on, the pings are answered:

15:13:57.289539 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.10.4 (52:75:9a:65:57:e4) tell 10.10.244.14, length 46
15:13:57.289945 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 128, id 31608, offset 0, flags [none], proto ICMP (1), length 84)
    10.10.10.4 > 10.10.244.14: ICMP echo reply, id 34083, seq 126, length 64
15:13:57.290001 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.10.10.4 is-at 52:75:9a:65:57:e4, length 46
15:13:58.292013 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 60751, offset 0, flags [none], proto ICMP (1), length 84)
    10.10.244.14 > 10.10.10.4: ICMP echo request, id 34083, seq 127, length 64
15:13:58.292336 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 128, id 31609, offset 0, flags [none], proto ICMP (1), length 84)
    10.10.10.4 > 10.10.244.14: ICMP echo reply, id 34083, seq 127, length 64

To me this looks as if the Windows server only updates its own ARP cache upon receiving an ARP request for its own address when it's a unicast request.

If I understand the RFC correctly, this doesn't seem to be the correct behavior. I understand that a recipient of an ARP request should always update its own ARP table if there is already an entry for the sending host, or insert a new entry for the sending host if the ARP request is for its own address.

Am I misreading the spec, or does Windows do something different? If the latter, is this behavior configurable?

Thanks for any pointers.

For some reason, ip -s link does not show the same numbers as /proc/net/dev, specifically the overrun count.

For a given interface, ip shows no overrun packets:

$ ip -s link show eth-ext1
7: eth-ext1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:08:a2:0d:00:74 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    1038103044434 1099087192 0       0       0       401298  
    TX: bytes  packets  errors  dropped carrier collsns 
    543051882227 844808055 0       0       0       0       

While in proc we see non-zero overrun (which is what I am assuming fifo is referring to):

$ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
[...]
eth-ext1: 1038106099296 1099090833    0    0 467554     0          0    401301 543052535442 844810749    0    0    0     0       0          0

I'm inclined to believe that there actually were overrun packets on the interface, so it appears that the output of ip link is not correct. Is there anything I am missing?

I've been trying to understand a peculiar behavior in our routing/firewall setup for quite some time now, but don't really understand what's going on.

We have a firewall/router appliance that has two external facing interfaces and a number of internal VLANs.

The specific behavior is observed when a client (MAC f4:f5:d8:d2:f2:4c, IP 10.99.154.254 in this example) on our guest WiFi network VLAN 99 sends a ping echo request to some internet host 8.8.8.8, which we prohibit.

The router sends back an ICMP host unreachable packet from its vlan99 interface (MAC 00:08:a2:0d:00:70, IP 10.99.0.2) to the client, and at the exact same time we see a martian packet on the external interface eth-ext1:

tcpdump shows this:

$ tcpdump -i vlan99 -vvvvn 'icmp and host 10.99.154.254'
11:59:21.555564 f4:f5:d8:d2:f2:4c > 00:08:a2:0d:00:70, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.99.154.254 > 8.8.8.8: ICMP echo request, id 2303, seq 1, length 64
11:59:21.555651 00:08:a2:0d:00:70 > f4:f5:d8:d2:f2:4c, ethertype IPv4 (0x0800), length 126: (tos 0xc0, ttl 64, id 8585, offset 0, flags [none], proto ICMP (1), length 112)
    10.99.0.2 > 10.99.154.254: ICMP host 8.8.8.8 unreachable, length 92
    (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.99.154.254 > 8.8.8.8: ICMP echo request, id 2303, seq 1, length 64

Nothing surprising here, this is the original ping from the client and the resulting ICMP packet going back to the guest client informing them that the host is unreachable.

At the same time, an entry appears in the kernel log:

Feb 21 11:59:21 ganymede kernel: IPv4: martian source 10.99.154.254 from 8.8.8.8, on dev eth-ext1
Feb 21 11:59:21 ganymede kernel: ll header: 00000000: 00 08 a2 0d 00 70 f4 f5 d8 d2 f2 4c 08 00        .....p.....L..

The link layer information shows that this ethernet frame came from the client device to the router's vlan99 interface, which makes me wonder why it appears as a martian packet on eth-ext1 with a source address of 8.8.8.8.

I have failed so far to get a trace of the packet with the martian source, which leaves me wondering if martian source logging also happens on an egress interface, before tcpdump has a chance to see it?

I'll gladly provide more information on request (routing tables or the like), and would appreciate any pointers as to what's going on here.

We have a machine running Ubuntu Precise Pangolin, which boots into initrd's busybox. From what I understand, this normally happens if the proper kernel can't be loaded. But in our case, a simple exit at the initrd prompt boots the system just fine without any errors or warnings.

What could be causing this? The relevant grub.cfg entry looks like this:

menuentry 'Ubuntu, with Linux 3.2.0-80-generic' --class ubuntu --class gnu-linux --class gnu --class os {
        recordfail
        gfxmode $linux_gfx_mode
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='(hd5,msdos1)'
        search --no-floppy --fs-uuid --set=root 0977ef08-2737-4d1d-9ec6-31f6719c3ad4
        linux   /boot/vmlinuz-3.2.0-80-generic root=UUID=0977ef08-2737-4d1d-9ec6-31f6719c3ad4 ro   splash quiet $vt_handoff
        initrd  /boot/initrd.img-3.2.0-80-generic
}

Today I've noticed that mod_alias's Redirect and RedirectMatch directives show a different behavior in how they handle the redirect URL.

A statement like this:

Redirect 301 "/foo" "/bar%20baz"

will redirect to the literal URL bar%20baz, whereas

RedirectMatch "/foo" "bar%20baz"

will redirect to bar%2520baz, as the redirect URL's percent sign is escaped.

My redirect URLs are already escaped. Is there any way I can tell RedirectMatch to not escape them any further?

I noticed the following today on our router:

user@router:~$ cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count 
28141

However:

user@router:~$ sudo conntrack -L > /dev/null 
conntrack v1.2.1 (conntrack-tools): 4652 flow entries have been shown.

user@router:~$ sudo conntrack -L expect > /dev/null 
conntrack v1.2.1 (conntrack-tools): 1 expectations have been shown.

My understanding is that ip_conntrack_count shows the number of entries of the conntrack table. What am I missing?

We're experiencing a peculiar issue with our bind installation (version 9.8.4).

In this scenario, bind is configured as a caching name server for a small network. For the large majority of queries, everything works fine.

However, we've noticed that queries for some hosts that are configured with a very low TTL, we sometimes get NXDOMAIN responses even though the host name exists.

As an example, take www.cdn77.com—here's the output of dig when run on the name server itself:

$ dig www.cdn77.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.cdn77.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34440
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 12

;; QUESTION SECTION:
;www.cdn77.com.         IN  A

;; ANSWER SECTION:
www.cdn77.com.      196 IN  CNAME   1669655317.rsc.cdn77.org.
1669655317.rsc.cdn77.org. 0 IN  A   185.59.220.12

;; AUTHORITY SECTION:
org.            170517  IN  NS  a2.org.afilias-nst.info.
org.            170517  IN  NS  c0.org.afilias-nst.info.
org.            170517  IN  NS  b0.org.afilias-nst.org.
org.            170517  IN  NS  d0.org.afilias-nst.org.
org.            170517  IN  NS  a0.org.afilias-nst.info.
org.            170517  IN  NS  b2.org.afilias-nst.org.

;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 170517 IN  A   199.19.56.1
a0.org.afilias-nst.info. 170517 IN  AAAA    2001:500:e::1
a2.org.afilias-nst.info. 170517 IN  A   199.249.112.1
a2.org.afilias-nst.info. 170517 IN  AAAA    2001:500:40::1
b0.org.afilias-nst.org. 170517  IN  A   199.19.54.1
b0.org.afilias-nst.org. 170517  IN  AAAA    2001:500:c::1
b2.org.afilias-nst.org. 170517  IN  A   199.249.120.1
b2.org.afilias-nst.org. 170517  IN  AAAA    2001:500:48::1
c0.org.afilias-nst.info. 170517 IN  A   199.19.53.1
c0.org.afilias-nst.info. 170517 IN  AAAA    2001:500:b::1
d0.org.afilias-nst.org. 170517  IN  A   199.19.57.1
d0.org.afilias-nst.org. 170517  IN  AAAA    2001:500:f::1

;; Query time: 42 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec  2 14:27:03 2015
;; MSG SIZE  rcvd: 487

And here's an example of when a NXDOMAIN response is returned:

$ dig www.cdn77.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.cdn77.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28771
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.cdn77.com.         IN  A

;; ANSWER SECTION:
www.cdn77.com.      327 IN  CNAME   1669655317.rsc.cdn77.org.

;; AUTHORITY SECTION:
cdn77.org.      59  IN  SOA ns1.cdn77.org. admin.cdn77.com. 1449062655 10800 180 604800 60

;; Query time: 34 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec  2 14:24:52 2015
;; MSG SIZE  rcvd: 115

We use Google's public name servers as forwarders, and they never seem to respond with NXDOMAIN:

$ dig www.cdn77.com @8.8.8.8

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.cdn77.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35091
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.cdn77.com.         IN  A

;; ANSWER SECTION:
www.cdn77.com.      851 IN  CNAME   1669655317.rsc.cdn77.org.
1669655317.rsc.cdn77.org. 0 IN  A   185.59.220.11

;; Query time: 40 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Dec  2 14:29:16 2015
;; MSG SIZE  rcvd: 85

The authoritive answer, by the way, looks like this:

$ dig 1669655317.rsc.cdn77.org @ns1.cdn77.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> 1669655317.rsc.cdn77.org @ns1.cdn77.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11529
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;1669655317.rsc.cdn77.org.  IN  A

;; ANSWER SECTION:
1669655317.rsc.cdn77.org. 1 IN  A   185.59.220.12

;; Query time: 20 msec
;; SERVER: 37.235.105.100#53(37.235.105.100)
;; WHEN: Wed Dec  2 14:32:57 2015
;; MSG SIZE  rcvd: 58

Interestingly, even though the authorative TTL for the record is one, Google's public nameserver always reduces it to zero (see this article for an interesting read about this behavior). I don't think this has anything to do with the problem though, as the successful responses from our bind also show TTL zero.

I've increased bind's logging level, but find it very hard to identify any entries that might have something to do with the problem. Even with querylog activated, all that's visible is the query itself and resolver: debug 1: createfetch: 1669655317.rsc.cdn77.org A lines.

Any pointers towards how to better diagnose (or even solve) this issue would be greatly appreciated.

I have a site-to-site IPsec tunnel up and running between a strongswan (v5.2.0) instance (site A) and a RouterOS router (site B). Everything works fine, the hosts in the two private subnets setup for site A (10.10.0.0/16) and B (10.50.0.0/16) can communicate with each other just fine.

What I don't understand though is the following output of ip xfrm policy on site A's router (public IPs obfuscated). Theses policies were created by strongswan, I did not manually install or modfify them:

ip xfrm policy 
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir fwd priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir in priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.10.0.0/16 dst 10.50.0.0/16 
    dir out priority 2947 ptype main 
    tmpl src <PUBLIC_IP_A> dst <PUBLIC_IP_B>
        proto esp reqid 1 mode tunnel

There's a policy each for input and output, but only one for forwarding (from site B to site A). But I can still successfully ping, for instance, 10.50.4.11 from 10.10.0.89:

ping -R 10.50.4.11
PING 10.50.4.11 (10.50.4.11): 56 data bytes
64 bytes from 10.50.4.11: icmp_seq=0 ttl=62 time=10.872 ms
RR:     10.10.0.89
    10.50.0.1
    10.50.4.11
    10.50.4.11
    10.50.4.11
    10.10.0.2
    10.10.0.89

The interesting part about this route trace is that site A's router (10.10.0.2) only shows up on the route back from the ping target, while site B's router (10.50.0.1) is only listed for the outgoing route.

This seems to confirm that there is actually no forward policy needed on site A's router to forward 10.10.0.0/16 to 10.50.0.0/16 over the IPsec tunnel, but I do not understand why.

Thanks for any explanations!

I recently migrated a small DNS setup from one machine to another. The only thing that changed was the version of bind in use:

root@old_box:~ $ named -V
BIND 9.7.0-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS='

versus

root@new_box:/etc# named -V
BIND 9.8.4-rpz2+rl005.12-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'
using OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
using libxml2 version: 2.8.0

CPU usage on the old box was between 0% and 5% while now it's more around 10%. These are very unscientific measurements, I know, but I wondered whether this was a common observation.

The behavior is as far as I can see not related to the known bug where BIND cannot create a managed-keys.bind file, as the symptom there would be close to 100% CPU usage.

Thanks for any pointers.

[e]: Michael Hampton made a valid comment about the machines themselves. They're both HP Micro Servers with an Athlon II Neo dual core processor at 800MHz. Both are rated at about 2600 bogomips according to /proc/cpuinfo, thus I think CPU percentage should be comparable between the two.

Specifically, I want the user to be able to create/delete his own access keys ("Action": ["iam:*AccessKey*"]) in the AWS console, but without giving them a full user list view in the IAM dashboard.

The instructions listed in the AWS documentation here add "Action": "iam:ListUsers" for all users to the policy, which is what I'd like to avoid.

I tried using

{
  "Sid":"AllowUserToListHimselfInConsole",
  "Action": "iam:ListUsers",
  "Effect": "Allow",
  "Resource": "arn:aws:iam::593145159899:user/${aws:username}"
}

to allow the user to just list his own account, but it didn't work.

Is there a way to do what I aim for, or is the full user list a prerequisite to be able to change your own credentials in the console?

I have an autonomous Cisco access point (model AP1142N) and an Apple TV that are on the same physical and logical network. Bonjour does not work across the access point — both WiFi-to-WiFi and Wired-to-Wired seem to work, but as soon as multicast traffic has to pass the access point, it is dropped.

There are many different (sometimes contradictory) purported solutions to that problem on the Cisco forums, here's just an excerpt:

• Deactivate IGMP snooping on all interfaces
• Enable IGMP snooping on the access point
• iOS v15 has broken Bonjour

I tried all suggestions that I could find, activated and deactivated IGMP snooping on all combinations of interfaces, but to no avail. It didn't matter whether I used iOS v12 or v15.

There is a lot of material for the lightweight (controller-based) version of this access point, but a lot less for the autonomous one.

I don't really know what to make of all this — right now I'm just curious if anyone has had any success at all in getting Bonjor to work with autonomous Cisco access points.

Thanks for any feedback!

Update: I just noticed that Bonjour works fine for iOS devices (tested with an iPhone 5 and an iPad Mini) on the same exact WiFi network! Now I am really stumped — I would figure that it either works for both OSes or none...

I am trying to create a site-to-site VPN between a Linux router that runs openswan and shorewall (host A, serving subnet 10.10.0.0/16) and a MikroTek RouterBoard running RouterOS 6.3 (host B, serving 192.168.88.0/24).

The IPSEC tunnel itself seems to be up, host A says:

# service ipsec status
IPsec running  - pluto pid: 4292
pluto pid 4292
1 tunnels up
some eroutes exist

and:

#ipsec auto --status
<SNIP>
000 #2: "office-connect":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27422s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
000 #2: "office-connect" esp.65bcd1d@<REDACTED> esp.c8d18ebd@<REDACTED> tun.0@<REDACTED> tun.0@<REDACTED> ref=0 refhim=4294901761
000 #1: "office-connect":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 2348s; newest ISAKMP; lastdpd=72s(seq in:0 out:0); idle; import:admin initiate

while on host B:

/ip ipsec remote-peers print
 0 local-address=<REDACTED> remote-address=<REDACTED> state=established side=responder established=11m26s 

and:

/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - inactive 
 0    src-address=192.168.88.0/24 src-port=any dst-address=10.10.0.0/16 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes 
      sa-src-address=<REDACTED> sa-dst-address=<REDACTED> proposal=Office-Connect priority=0

I followed the instrutions on http://www.shorewall.net/IPSEC-2.6.html to configure shorewall and http://wiki.mikrotik.com/wiki/Manual:IP/IPsec to setup a NAT Bypass rule.

However, I can't actually get any packets through the tunnel, on A:

# ping -c4 192.168.88.1
PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.

--- 192.168.88.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3016ms

on B:

/ping count=4 10.10.0.1
HOST                                     SIZE TTL TIME  STATUS                                                                                               
10.10.0.1                                               timeout                                                                                              
10.10.0.1                                               timeout                                                                                              
10.10.0.1                                               timeout                                                                                              
10.10.0.1                                               timeout                                                                                              
    sent=4 received=0 packet-loss=100% 

I am at a bit of a loss how to proceed, my experience in networking is not too great. So I'd be helpful for any hints, even just how to debug this problem. I'll gladly provide additional configuration samples or log output if required. Many thanks!

I have a Cisco AP1142N in standalone mode acting as a simple AP. On the wired segment of the LAN, there is an Apple TV that is used to mirror laptop screens to a large TV screen.

As long as clients are in the wired LAN, they can see and stream to the Apple TV without issue. It doesn't work when they are associated with the WLAN, though.

It appears to me that this is a problem with the multicast mDNS queries not being able to cross segments. Interestingly, according to iperf, multicast traffic from the WiFi to the wired network is working, but not the other way around.

I stumbled upon some posts (example) on the Cisco support forum indicating that IGMP snooping should be deactivated to make multicast "just work", so I did that:

>show ip igmp snooping 
Global IGMP Snooping configuration:
-----------------------------------
IGMP snooping             : Disabled
IGMPv3 snooping           : Disabled
Report suppression        : Disabled
TCN solicit query         : Disabled
TCN flood query count     : 2

Vlan 10:
--------
IGMP snooping                       : Disabled
IGMPv2 immediate leave              : Disabled
Explicit host tracking              : Enabled
Multicast router learning mode      : pim-dvmrp
CGMP interoperability mode          : IGMP_ONLY

Vlan 99:
--------
IGMP snooping                       : Disabled
IGMPv2 immediate leave              : Disabled
Explicit host tracking              : Enabled
Multicast router learning mode      : pim-dvmrp
CGMP interoperability mode          : IGMP_ONLY

But the situation is still the same: WiFi to wired multicast works, the other way around does not; thus the WiFi users cannot see the Apple TV.

What other settings do I need to change in order to get mDNS working across the access point?

After restarting a XCP 1.6.10 host machine, XenCenter 6.1 is no longer able to connect to it. The failure message is always "Server failure: Unauthorized". Using ssh with the exact same root credentials works fine.

I can't seem to find any log on the box that would help me to diagnose this issue, is there any place where connection attempts to openwsmand are logged?

I use nginx as a simple SSL proxy and have 7 virtual hosts configured (plus a default host). Interestingly, whenever I restart the server, I have to enter the PEM pass phrase for my private key 20(!) times, which gets old really quick. The number of prompts has increased with the number of hosts defined.

I have set up SSL-enabled hosts with Apache in the past, and there I only had to enter the pass phrase for every key a single time, no matter how many virtual hosts were using that key.

Is there any possibility to make nginx behave more like apache in this regard and only ask once for the same pass phrase?